D11979: Automatically show and hide selection markers based on single click/double click setting

[Henrik Fehlauer]

rkflx added a comment.


  Your patch is too imbalanced: You gain a checkbox which effectively results in Dolphin working like macOS Finder with a single switch (instead of with two switches to toggle like right now), but at the same time you regress in usability and functionality over the existing state of both KDE and Windows. Double-click users cannot turn on the markers anymore, and single-click users won't be able to turn them off.
  
  Only to save users of a non-default option one extra step you make workflows of other users totally impossible. At least to me that's not a good incentive to accept the patch.
  
  ---
  
  > But if you change the setting to double-click, they become useless annoyances: clicking anywhere on an icon selects it, so there's no need for a tiny hover button in the corner to provide this feature.
  
  No they are not annoyances, because they provide an essential role to make selecting multiple items easier. If we'd followed your arguments, we'd have to remove the markers altogether, because for single-click you could just use [Ctrl] like you are proposing for double-click. Don't forget that selecting a single item has no value on its own, because right-clicking to open the context menu will already select the item if it isn't selected, for drag-and-drop a pre-existing selection is no prerequisite too, and for the information panel hovering is enough.
  
  The important case the selection-marker is needed for is for multi-selection, and thus absolutely independent of the number of clicks. Therefore binding those markers to the click behaviour is wrong. As said elsewhere, improving the hover marker in appearance and functionality could be worthwhile, but simply removing it //everywhere// is the worst of all options.
  
  In D11979#241191 <https://phabricator.kde.org/D11979#241191>, @ngraham wrote:
  
  > Other desktops use double-click as the selection/opening behavior and have no option to add selection markers (except for Windows which does have that option, I believe). So Dolphin would actually be more consistent with other platforms.
  
  
  Maybe users e.g. on XFCE specifically chose Dolphin to have the markers, because their default file manager does not have them. Now you are saying they are not allowed to have the markers anymore, because they chose the wrong desktop…
  
  > In D11979#241188 <https://phabricator.kde.org/D11979#241188>, @rkflx wrote:
  > 
  >> In D11979#241177 <https://phabricator.kde.org/D11979#241177>, @ngraham wrote:
  >>
  >> > From a normal user's perspective, there's no distinction between files and folders on the desktop and files and folders in Dolphin.
  >>
  >>
  >> Hm, for example entering a folder is vastly different.
  > 
  > 
  > I'm talking about the user's mental model not the current state of affairs. Also, opening a folder in Folder view just opens Dolphin by default, so I'm not sure what difference you're referring to? Maybe the drag-and-hover behavior?
  
  Exactly, you cannot "open" a folder on the desktop, it will launch an external app instead. IOW, "total" consistency regarding the marker behaviour is not needed, because there are already many differences between how folder view and Dolphin behave.
  
  ---
  
  @ngraham Sorry for the negativity. I hope you see my arguments as purely on-topic and not against you personally. I also thought for quite a bit on how to make this "click here to make it behave in a certain way" you want easier, but in this case there isn't really a good option. The extra toggle in Dolphin (and Gwenview) is likely just the best way…

REPOSITORY
  R318 Dolphin

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

To: ngraham, #dolphin, rkflx
Cc: rkflx, broulik, anthonyfieroni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180406/cc1de97d/attachment.htm>