Bug 160557

I agree even with this.

@Simon: what do you think about this?

I agree too... as single-click only selects a module unnecessary. take for example, dolphin in kde 4.1+, when we enable double click (mouse settings), the "Places" buttons works with single click, whereas folder views etc. requires double click. Which is an expected behavior.

Please consider single-click to execute the modules in system-settings, in kde 4.2. Thanks.

Since I was about to report this to, I wanted to say that I strongly agree with this. system-settings modules should be opened with single click.
The need to double-click these is inconsistent with similar areas like the mentioned "Places" button in Dolphin as well as switching between related modules (left hand panel in most modules) in system-settings itself.

Besides for me (KDE 4.1.2 on Kubuntu Hardy) the mouse setting responsible for double-click states "Double-click to open files and folders (select icons on first click)", so it should not apply to system-settings modules anyway and considered a bug.

My thoughts on it:
The menu items in System Settings behave like buttons,  The items changes when the mouse is over it.. like a good button.

These may logically be files, as with the classic windows XP control panel, but note the windows people didn't try to make icons act like buttons, they made a seporate mode with actual buttons...

Another factor here may be due to the  reclassification of icon configuration. KDE puts it globally under Keyboard and Mouse.  I have mixed feelings on this because it might help with gobal configuration of doubleclick,   There probably is a way to override for individual areas.

some ideas about mouse configuration (very very rough) http://catproof.site90.com/node/2

*** Bug 168165 has been marked as a duplicate of this bug. ***

I understand your reasoning but I disagree -- Konqueror, Dolphin, and SS show pretty the same content, icons looks the same, labels looks the same, and now all of the sudden user has to remember exactly which app violates settings and which does not violate the settings.

UI should be consistent in whole KDE, without taking "short paths".

(In reply to comment #7)

>... icons looks the same, 
If they represent files, they don't act like it.  Really it comes down to how they are to be used.   If they need to behave like buttons, they need to operate like buttons.  When it comes down to it everything can be represented by a file.  The system settings layout is very good,

 I sat down infront of a vista computer, and saw an AOL menu like mess of cluttered icons and was very glad that I have KDE.  Microsoft  totally botched their Vista control panel, LOL, they even lost their file like view of them.

Main confusing thing with KDE is that somebody made a setting global in a way that isn't sensitive with how things are actually used.  I'll work a bit more on my UI event classification at catproof

labels looks the same, and now
> all of the sudden user has to remember exactly which app violates settings and
> which does not violate the settings.

 System Settings violates that.

> 
> UI should be consistent in whole KDE, without taking "short paths".
> 
Exactly, the System Settings behave like buttons, so we should interact with them like buttons.    Right now somebody took a shortcut to make everything require manipulation in the same way, regardless if it makes sense or not.

System Settings is by far the best start in system configuration management that I have seen.  It just needs a few tweaks.

I'll take a look at the code, and it's probably a one line fix. I'll be unable to fix it because I don't have the development environment up yet :(   

This should probably be classified as a Jr Job

> Exactly, the System Settings behave like buttons,

And that's unfortunate because they don't look like buttons. And besides, they only partially behave like buttons, and it may (and I hope it will) change in future -- https://bugs.kde.org/show_bug.cgi?id=175278.

With list or tree you are right, buttons are there, but with current layout there is more resemblance to konqueror or dolphin than to buttons.

So, I say if we already have dolphin-like interface let's rather add flexibility than downgrade it to something static.

Logically these are toolbars.  It is probably too much work to change them into that, it looks like these are nicely sorted.

    tv->setSelectionMode(QAbstractItemView::SingleSelection);
Should probably be set to  NoSelection...  It doesn't make sense to select these, but it does make sense to have focus (I don't know how QT deals with selection vs focus) -- ultimately it doesn't matter and this could probably be the same.

  ***  fix, add this line or one like it ***
   tv->setEditTriggers(QAbstractItemView::SelectedClicked);
***

http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKCategorizedView.html
http://doc.trolltech.com/4.4/qlistview.html

**This is where the solution was found**
http://doc.trolltech.com/4.1/qabstractitemview.html

http://techbase.kde.org/Projects/SystemSettings

The code in question:
http://websvn.kde.org/trunk/KDE/kdebase/workspace/systemsettings/mainwindow.cpp?revision=869272&view=markup

QAbstractItemView::EditTriggers
This value should probably be 2+4+8  = 14
(assuming the edit key is [enter], or main click (left on most) from mouse.

*** Bug 178899 has been marked as a duplicate of this bug. ***

The single-click behaviour of systemsettings in earlier versions drove me absolutely up the wall. The fact that it gratuitously ignored my global settings eventually led to me yelling at the screen. I can't think of much worse than an application which presents standard UI elements and then proceeds to make interaction with them behave unlike the rest of the system, and was ecstatic when this bug was fixed in the KDE4 version. Please don't bring it back; systemsettings is bad enough as it is.

the double click preferences is for ICONS 

will you force people to double click everywhere?

why isn't the doubleclick preference used everywhere then? such as the kmenu ? buttons, etc?

selecting multiple items in the system settings it meaning less.
right click does nothing. therefor there is only one action possible related to a click. open the damn thing.

UI dudes.

> the double click preferences is for ICONS

Those in toolbars too?

> selecting multiple items in the system settings it meaning less.

_Now_. It should change.

> right click does nothing. 

So? You don't click to select/execute with RMB, do you?

> therefor there is only one action 
> possible related to a click. open the damn thing.

Or select. It is no point to cripple SS now, because other features are missing, and then revert it back, when there will be more features.

It only will make people mad, because UI would constantly change, and such way of developing is very error-prone.

If one thing is already made well, let's wait for other features to be added.

Just my 2¢:
The action for starting a SS module should correspond to the settings a user has chosen for "Keyboard & Mouse".
Thus I agree to the OP as I use "Single-click to open files and folders" and I really don't understand why this is overridden in SS.

>the double click preferences is for ICONS 
... that represent files--items that can be selected, moved, have keyboard focus, and be executed.

It could be said that Icons are everywhere...  The mouse/keyboard control panel isn't the way to define what items need to be handled carefully... it is where to establish the convention on how to handle items deemed to be this way. 

 I need/require a file manager to treat files as potentially dangerous when executed, opened, read, etc... I want all representation of files to be consistent.  I don't want my buttons to behave this way, because that will train my body to perform the "dangerous action enable dance" by default, which defeats the purpose.


Items in the control panel do  not directly correlate with files. They are all to be known safe, and need to be browsed like hyperlinks, or buttons. (preferably buttons)  (Hyperlinks have the cursor change over them to indicate action will occur, and buttons have a thematic element that make them indication action will occur if they are clicked.


It does not make sense for these items in the control panel to be selected.  It DOES make sense for them to have FOCUS,   They presently cannot be rearranged like file icons, they open in the system settings window, making system settings be a browser...  The control panel acts as a table of contents, like hyperlinks or buttons!   They most definitely are not file icons. and the user interface makes these behave like buttons..  They do, unfortunately, superficially look like file icons in the default settings, which obviously is a source of confusion.. because they are NOT (in usage at least)

 So, we have options. 

 1. make them file icons -- meaning they do not take control of the system settings window... . but it would cause a lot of individual system settings windows to need management... This has the benefit of being standard, and following that system preference.  and We could use DETAILS view to see comments.

2. Make them a dynamically generated list of hyperlinks/ buttons (As they are now).. and make them behave like it.
   To keep people from being confused we need to make them so they don't look like file icons (they don't on my system because I use details view exclusively for files), 

3. Replace the system settings window with a web browser / web based configuration tool.

Side note:h

I personally believe that the Yes button on a "do you want to open or execute this downloaded file" dialog should be a double click(or some other tamper resistant action (but the delay in activation in mozilla on this dialog is annoying, but could be presented as an option because somebody obviously wanted it)

> It does not make sense for these items in the control panel to be
> selected.
(...)
> They 
> presently cannot be rearranged like file icons, 

So it _does_ make sense to select them, because rearranging will change in future.

> It does not make sense for these items in the control panel to be
> selected.
(...)
> They 
> presently cannot be rearranged like file icons, 

>So it _does_ make sense to select them, because rearranging will change in
>future.

Right now, they show up as the result of a query, they are not file icons. 

 If you want them to be file icons, they need to really represent files... and open the application in a new window, and single click is select.

If you want them to be in their own special browser window, they need to act like hyperlinks or buttons.  

I like the way it is now except for the fact that their context prompts for  single click,  and It forces people to be confused between double and single click.  Making people double click where not indicated is a security vulnerability because it trains people to double click everything-- including the bad stuff.

> Right now, they show up as the result of a query, they are not file
> icons.
>
>  If you want them to be file icons, they need to really represent
> files... 

Something that can be rearranged does not have to be a file icon.

> Making people double click where
> not indicated is a security vulnerability because it trains people
> to double click everything-- including the bad stuff.

Switch KDE for single click and then complain that it trains users to click everywhere, even on bad stuff.

>Switch KDE for single click and then complain that it trains users to click
>everywhere, even on bad stuff.

 There should be no bad stuff that occurs on a single click... (In default configuration, there needs to be some other accessibility option for people who can't double click)

KDE generally doesn't do dangerous stuff on single clicks (GNOME and OSX are horrible, windows is generally ok, on gnome my system configuration changed because of just looking at it wrong)

We generally can't work with single click as default anyway because:
1. we are already trained / used to work with single / double click
2. There is a bug on practically all track pad computers where simply moving the finger across the pad results in tons and tons of "taps", and at least on Vista and Kubuntu/Ubuntu it appears that this "tap more times on everything whenever you try to move the cursor over it" "feature" is enabled... resulting in random windows popping up for most users. (including dangerous items)

Needing to have double click by default for file icon activation is a separate bug..


Here is another situation:
An OK dialog to reformat the harddrive.. maybe should be set up with an accident resistant click system.. (think Arkanoid-- the bricks game with the paddle and the ball. where the bricks show damage)

In practice this dialog is exempt because the user initiated it, so clicking the OK is the second click.. but it's still not optimal.. Dialog boxes are disorienting and other bad stuff, but that's another war...

The only way to implement this is through using the clicked() signal instead of activate(). This breaks keyboard navigation of the modules, which is not acceptable.

As a result, this can never be implemented unless other workarounds are available.
( I don't particularly like the idea anyway as it breaks behaviour with other applications )

I really don't understand this discussion. The items in the tree should respond to single clicks, or at least respect the global single/double-click setting. That seems as obvious to me as anything. Arguments about files and icons and whatnot seem completely irrelevant.

I also don't understand why this bug has been marked resolved when it isn't.

Not every user uses tree view mode.

The activated() signal recieved by System Settings from the Icon View or Tree View always follows the system wide setting, although that may only occur when a KStyle based Qt style is used, such as Oxygen.

Anybody care about setting up more generalized and configurable selection capabilities based on risk, use and user capabilities?

Gestures, key combos, and mouse clicks / alternate mouse clicks / multi touch / keyboard?

Also, setting up the kde development environment isn't that easy.

reminding... this is still a bug in 4.8.2