D15071: Don't draw frames and shadows around images with transparency

[Stefan Brüns]

bruns added a comment.


  In D15071#315839 <https://phabricator.kde.org/D15071#315839>, @broulik wrote:
  
  > I'm a bit concerned that removing the frame most of the time blurs the lines between "previews of images" and "actual file icons", especially for the SVG case.
  >
  > Now they all look like proper file icons rather than previews of the file's contents. I can see that an EXE "thumbnail" is a proper file icon but in many other cases it's misleading.
  
  
  I think the distinction should be between "Documents" and "Activatable items". Examples for the second category:
  
  - Folders (clicking enters the folder)
  - Executables (starts the program)
  - *.desktop files (starts the referenced program)
  
  Clicking on a document opens it in the associated applicaton (mime based).
  
  Now, confusion happens if you see e.g. the "Blender" icon - will a click open blender, or inkscape/gimp? Folder icon - dolphin or image editor?
  
  I think the confusion will be very rare - this only happens when the user browses e.g. /usr/share/icons/highcolor/*. In case a user takes an icon for the application, the worst thing that will happen is the wrong application is started.
  
  On the other hand, mistaking an application for a document may be bad. Think of an *.exe with an embedded icon which looks like a picture. This icon is passed to the UI unaltered. The current frame is hardly noticable form image previews, so confusion is easy - regardless if we add a frame or not. I think we have this somewhat covered by showing a warning if an executable is not in a trusted location.
  
  If we want to avoid **dangerous** confusion, we should not care for previews, but mark executables.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D15071

To: ngraham, #frameworks, #dolphin, #vdg, broulik, cfeck
Cc: anthonyfieroni, markg, abetts, bruns, kde-frameworks-devel, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180827/c59ff0d9/attachment.html>