D12327: Show Detailed Tree View by default

[Nathaniel Graham]

ngraham added a comment.


  Reasons to change the default to Detailed View or Detailed Tree View:
  
  - Ergonomics: the current default requires side-scrolling for long lists, which is almost never ideal
  - Usefulness: by showing the details columns by default (which also makes sorting more discoverable for this view), we're helping users find their content by more than just the filename
  - Bandwagon: Windows and GNOME do it (macOS probably would if they didn't have column view)
  
  Reasons to use Detailed Tree View as the default instead of Detailed View:
  
  - Usefulness: allowing expansion is a useful feature
  - Flexibility: allowing expansion helps advanced users navigate the hierarchy using the arrows to expand and collapse nodes, while allowing normal users to completely ignore the arrows and just navigate by clicking on folders and using the back button in the toolbar
  - Consistency: Dolphin's default default-style view allows expansion by default
  - Bandwagon: Windows and macOS's default details style views allow expansion by default too
  
  
  
  In D12327#250801 <https://phabricator.kde.org/D12327#250801>, @rkflx wrote:
  
  > One more idea: We could go all the way to a Windows style file dialog, i.e. use a single button to switch views, which has //all// options in it:
  >
  > - Short View > Next to Filename (needs new name)
  > - Short View > Above to Filename (needs new name)
  > - Detailed View
  > - [ ] Show tree expanders which would be disabled for Above Filename (needs better wording, of course)
  >
  >   ---
  >
  >   Edit 1: With this it would be easier to access all modes, so there would be less need to do a controversial change of default.
  >
  >   Edit 2: Hm I like this idea quite a lot, actually. @ngraham Could you give it a chance?
  
  
  Sorry, I'm not a big fan of this. I feel like that would dilute the task-centric focus that we're going for here. You've previously argued that allowing access to advanced functionality via the Settings manu is fine, and it will of course all remain there. The point of the toolbar is to allow quick access to a pre-selected, curated assortment of the functionality that we the developers deem most useful by default. For advanced users who feel constrained by this, the toolbar should simple be editable.
  
  Technically, it's somewhat problematic because your proposal would break the nice tidy 1:1 mapping of modes that the file dialog provides to modes that `KDirOperator` provides.

REPOSITORY
  R241 KIO

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

To: ngraham, #frameworks, #vdg, rkflx
Cc: elvisangelaccio, abetts, #frameworks, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180421/a0ef3903/attachment.html>