I can confirm this problem for some applications.

I am using System Settings 5.5.5 (KDE Frameworks 5.21.0, Qt 5.5.1), and System Settings->Input Devices->Mouse->Icons is set to "Double-click to open files and folders (select icons on first click)".  This setting works in most applications, but in the file selection dialog of other applications, it does not work.  For example, it works in the File->Open dialog of Kate and KWrite, but not in the File->Open dialog of KMail.

@Tristan Miller:
Your problem may be bug#367074.

Can you confirm that double-click works in those (KDE4) applications if you switch to *single-click* in the settings?

The original problem seems to be different though, as it is about icons on the desktop.

Yes, switching to single-click makes the KMail 4.14.10 file selector require double-clicking.  So I guess I am suffering from Bug 367074, not this one.

Regarding the original problem:
The setting works fine with icons in a folderview applet, but apparently "icon" plasmoids and the "trash" plasmoid (maybe others too?) do not respect the setting.

Not a bug in systemsettings though, rather in those applets, I think.
Reassigning to Plasma therefore and adjusting the title.

fixes on review, should be in the next release

Git commit 865901eed0781faa85e10625660daf699a171d76 by David Edmundson.
Committed on 30/08/2016 at 15:50.
Pushed by davidedmundson into branch 'master'.

Revert "Make icon follow styleHints"

This reverts commit f9689bfcd922b652e1b50d48cabb53468a2f5d8e.

Decision was this leads to an inconsistency in behaviour amongst
panel applets

M  +1    -4    applets/icon/package/contents/ui/main.qml

http://commits.kde.org/plasma-workspace/865901eed0781faa85e10625660daf699a171d76

From usability team:

The only raison d'être for "double-click to open" is to be able to select on single click. If selecting is not possible (as is the case both in the panel and in a desktop containment), there is no reason for opening only on double-click (other than consistency with Windows, but an icon widget in a Desktop containment is not the same as an icon on the Windows desktop, because the Windows desktop behaves like our folderview containment, not like our desktop containment).

Thanks for the report anyway.

There is a reason for requiring double click even when it isn't possible to select on single click: when you use the double click to open setting, muscle-memory means you tend to double click on those plasmoids. Since they open on single click, you get two Dolphin windows opening.

David, it is possible to ignore the second click if that is within the double-click timeout. Would you accept such patch?

(In reply to Christoph Feck from comment #9)
> David, it is possible to ignore the second click if that is within the
> double-click timeout. Would you accept such patch?

No, double click is double click. We will have that again.

(In reply to Hanisch from comment #10)
> (In reply to Christoph Feck from comment #9)
> > David, it is possible to ignore the second click if that is within the
> > double-click timeout. Would you accept such patch?
> 
> No, double click is double click. We will have that again.

I agree with David's comment that purely reflecting the setting for files and folders makes the panel inconsistent. Either the behavior should be single-click in the panel and double click on the desktop, or the second click should be ignored.

(In reply to David Edmundson from comment #7)
> From usability team:
> 
> The only raison d'être for "double-click to open" is to be able to select on
> single click. If selecting is not possible (as is the case both in the panel
> and in a desktop containment), there is no reason for opening only on
> double-click (other than consistency with Windows, but an icon widget in a
> Desktop containment is not the same as an icon on the Windows desktop,
> because the Windows desktop behaves like our folderview containment, not
> like our desktop containment).
> 
> Thanks for the report anyway.

The ability of selection is NOT the only purpose of "double-click to open" option. The main reason why it is necessary is that it prevents efficiently the accidental launching of an application from Desktop. I do need this option working for all objects located on my Desktop because I suppose that situation when anything launches from my Desktop by single click has no right to existence, and I suppose a lot of users would agree with me. Currently I use only "Folder view" namely due to this reason. Unfortunately, using of the Trashcan as a link instead of Trashcan widget is a bit inconvenient because its icon does not indicate "empty/full" state, and there is a problem with its positioning in the right lower corner. At the same time, the Trashcan widget launches the Dolphin with a single click, that increases the probability of its accidental launching significantly, and in my Celeron Core Duo 1600Hz it steals several seconds from me. 
For panels it is not a problem because they are located at margins.
And your statement that "icon widget in a Desktop containment is not the same as an icon on the Windows desktop, because the Windows desktop behaves like our folderview containment" is not correct for the Trashcan because the Trashcan in Windows has no aforementioned problems of Trashcan link in Plasma's Folder View (absence of emptiness indication and problem with positioning in right lower corner). 
So, the correct treatment of "double-click to open" option for widget launchers, and first of all for the Trashcan widget is absolutely necessary for Plasma, and its absence is the MOST irritating bug of Plasma 5 in its current state.

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

I fully agree with your comment.  
I am still having this same problem (not being able to configure desktop icons to open with 2-clicks) in  Plasma v. 5.14.5 under Debian Buster.
And I consider it as well highly annoying exactly for the reasons you are telling.

I would like to ask KDE team what "Resolved Intentional" actually means: is it just a polite way to tell that KDE has no intention to allow for this option ? it would really be a pity for an otherwise excellent desktop.
So I am confident that they want to pay attention to this issue, and thanks in advance for that.

> is it just a polite way to tell that KDE has no intention to allow for this option ? 

Effectively, yes. Sorry.

I wrote a patch initially for this behaviour, I had to revert it because of feedback. Nothing has changed since. I consider it way too niche for an additional option.

You can either apply https://cgit.kde.org/plasma-workspace.git/commit/?id=f9689bfcd922b652e1b50d48cabb53468a2f5d8e locally or instead of using icon and trash plasmoids add relevant .desktop files to your Desktop folderview.

(In reply to David Edmundson from comment #15)

  Thanks for replying.

> > is it just a polite way to tell that KDE has no intention to allow for this option ? 
> 
> Effectively, yes. Sorry.
> 
> I wrote a patch initially for this behaviour, I had to revert it because of
> feedback. Nothing has changed since. I consider it way too niche for an
> additional option.

Although I doubt that the requirement be "too niche", for the reasons already well explained by M. Vishap, I cannot but take note. 

> 
> You can either apply
> https://cgit.kde.org/plasma-workspace.git/commit/
> ?id=f9689bfcd922b652e1b50d48cabb53468a2f5d8e locally 

I would like to apply your patch, but my experience in doing that is very limited: may I ask you to provide some guidelines on how to download the .diff
and apply it. 
I see that changes are quite simple and could be just applied by editing the 
object file, but I cannot find the "main.qml" file.

Thanks in advance for your patience and help.
Giuliano Cabrele