[KDirOperator] Show Detailed Tree View by default
ClosedPublic

Authored by ngraham on Apr 18 2018, 7:55 PM.

Details

Summary

Show Detailed Tree View by default in KDirOperator. This only affects the file open/save dialogs, because all other clients set their preferred view mode manually (checked with lxr and submitted patches that have been accepted for the two that didn't).

This change will result in Open & Save dialogs displaying Detailed Tree View by default instead of Simple View.

Detailed Tree View is better for content that is optimally located by its filename or metadata, which I would wager is more common, so it should be the default view. Also, bandwagon argument: Windows and GNOME both display the same view by default in their Open/Save dialogs now (macOS displays the navigation-friendly {Column View} by default, which sadly lacks a KDE equivalent).

Test Plan

Tested in a new user account and opened an Open dialog from Kate:

Diff Detail

Repository
R241 KIO
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
ngraham created this revision.Apr 18 2018, 7:55 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptApr 18 2018, 7:55 PM
Restricted Application added a subscriber: Frameworks. · View Herald Transcript
ngraham requested review of this revision.Apr 18 2018, 7:55 PM
ngraham edited the summary of this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)
ngraham edited the summary of this revision. (Show Details)Apr 18 2018, 8:09 PM
ngraham retitled this revision from [WIP/open dependencies] Show Detailed Tree View by default to Show Detailed Tree View by default.Apr 20 2018, 3:46 AM
ngraham edited the summary of this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)
ngraham added reviewers: Frameworks, VDG, rkflx.

I'm not sure I agree with this change, and afaik Windows does not show the tree view by default in its file dialogs (unless you are referring to FolderBrowserDialog from .Net)

rkflx added a comment.EditedApr 21 2018, 10:03 AM

I'm not sure I agree with this change

At least it's not a -1 yet, so maybe we can convince you once everything is in place…!?

afaik Windows does not show the tree view by default in its file dialogs (unless you are referring to FolderBrowserDialog from .Net)

Testing Internet Explorer, Paint and Notepad, all show this detailed view (Explorer too!). Only when switching to the Pictures folder the view is changed to "text under icons". For a non-Microsoft app I tested Firefox, which also has detailed view. If you asked me, I'd say that's the default experience people get on Windows.

Nevertheless, copying Windows is not the main point. We should switch defaults if we determine it's the best for KDE's apps. Reasons for that might be:

  • Vertical scrolling is awkward, often people don't realize they can use their scroll wheel or touchpad and resort to move the scrollbar instead.
  • Continuously reading and scrolling a vertical list may allow finding a file faster than jumping back and forth in the vertical-and-horizontal placement with more horizontal scrolling in between.
  • Sorting is more natural, with quicker access (thus used more often) to toggle between time and name based sorting.
  • Clear separation between the details mode and the more visual Simple View. We cannot turn on "text under icons", a bigger icon size and thumbnails if Simple View was to stay the default mode, because that would not work well for the general use case and show too few items at once.

@ngraham Anything I missed?

As a sort of compromise we could keep the current default, but add a third button like in Dolphin. That needs more space, has some caveats and is more complicated to implement, though. Food for thought.

I'm not sure I agree with this change

At least it's not a -1 yet, so maybe we can convince you once everything is in place…!?

afaik Windows does not show the tree view by default in its file dialogs (unless you are referring to FolderBrowserDialog from .Net)

Testing Internet Explorer, Paint and Notepad, all show this detailed view (Explorer too!). Only when switching to the Pictures folder the view is changed to "text under icons". For a non-Microsoft app I tested Firefox, which also has detailed view. If you asked me, I'd say that's the default experience people get on Windows.

But Detailed View and Detailed Tree View are two different things, no? (I'm not even sure Windows supports the latter)

But Detailed View and Detailed Tree View are two different things, no? (I'm not even sure Windows supports the latter)

That's correct, Windows does not support the latter. In D12077 the button was added (sadly Nate thought it was enough to ask on IRC and Telegram regarding my suggestion to wait for one extra approval…), where we used the Tree variant for the more detailed view.

We could backtrack on that and use the non-tree variant, but personally I find it quite fitting for this mode to also allow expanding folders without navigating there, as it might allow to find things faster when not having to go back. Admittedly it adds some amount of visual noise.

Thoughts?

rkflx added a comment.EditedApr 21 2018, 11:19 AM

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 ViewNext to Filename (needs new name)
  • Short ViewAbove to Filename (needs new name)
  • Detailed View
  • Tree View
  • Detailed Tree View

Or, consolidating a bit:

  • Short ViewNext to Filename (needs new name)
  • Short ViewAbove 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?

ngraham added a comment.EditedApr 21 2018, 1:23 PM

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

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 ViewNext to Filename (needs new name)
  • Short ViewAbove 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?

I agree with you that it would be better if Icons view and Compact view were separate modes (like Dolphin) and Details view were only a single one that simply presented the option to turn the expansion arrows on or off (again like Dolphin). The technical problem with this is that it breaks the nice tidy 1:1 mapping of modes that the file dialog provides to modes that KDirOperator provides. And we can't easily change this in KDirOperator without patching all clients to cope with the change in advance (which of course is possible but could be a mess).

As for allowing access to all view modes via the toolbar: Sorry, I'm not a big fan. 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.

I think it's best to have two buttons, each corresponding to a very different style of view that's optimized for a clear use case.

Or, a compromise: If we wanted to go all the way and have Dolphin-style options (Icons View, Compact view, Detailed view), I could support that for consistency's sake as long as we have three buttons like Dolphin does, rather than a combobox or a drop-down menu. That would still run into the technical challenges that I outlined above though.

rkflx added a comment.Apr 21 2018, 1:40 PM
  • Bandwagon: Windows and macOS's default details style views allow expansion by default too

I'm all for going tree-style, but honestly I don't see expansion in Windows? Are we testing different versions? (In case they are fictitious, that would not help your point.)

You've previously argued that allowing access to advanced functionality via the Settings manu is fine, and it will of course all remain there.

You are right of course. I was going for a fallback option here: If we cannot agree to your original proposal, accessing the view modes via a dedicated button would still be preferable over having to go into an additional submenu in the generic settings button, though.

I think it's best to have two buttons, each corresponding to a very different style of view that's optimized for a clear use case.

That would be ideal, of course.

Or, a compromise: If we wanted to go all the way and have Dolphin-style options (Icons View, Compact view, Detailed view), I could support that for consistency's sake as long as we have three buttons like Dolphin does, rather than a combobox or a drop-down menu. That would still run into the technical challenges that I outlined above though.

As hinted at before, I could agree to that. However, we need more space then. How about moving Up, i.e. only a single button, in front of the breadcrumb bar? Would help in Dolphin too, and has been seen in Windows before, while avoiding some of the problems with moving every navigation button there, like you proposed elsewhere.

  • Bandwagon: Windows and macOS's default details style views allow expansion by default too

I'm all for going tree-style, but honestly I don't see expansion in Windows? Are we testing different versions? (In case they are fictitious, that would not help your point.)

Ah, you're right, never mind. In Windows 10, even with 8 (8!) view modes, none of them allow tree-style expansion.

I think it's best to have two buttons, each corresponding to a very different style of view that's optimized for a clear use case.

That would be ideal, of course.

Yes I think we should shoot for that, if possible.

Or, a compromise: If we wanted to go all the way and have Dolphin-style options (Icons View, Compact view, Detailed view), I could support that for consistency's sake as long as we have three buttons like Dolphin does, rather than a combobox or a drop-down menu. That would still run into the technical challenges that I outlined above though.

As hinted at before, I could agree to that. However, we need more space then. How about moving Up, i.e. only a single button, in front of the breadcrumb bar? Would help in Dolphin too, and has been seen in Windows before, while avoiding some of the problems with moving every navigation button there, like you proposed elsewhere.

In fact, if we integrated the Up button into the KURLNavigator widget, it would solve some issues automatically (e.g. lack of up button in Gwenview). I could see some people complaining about it though, because then the navigation buttons would be in two different vertical planes (since the URL navigator is always below the toolbar). Maybe we could live with that though?

rkflx added a comment.Apr 21 2018, 1:54 PM

In fact, if we integrated the Up button into the KURLNavigator widget, it would solve some issues automatically (e.g. lack of up button in Gwenview). I could see some people complaining about it though, because then the navigation buttons would be in two different vertical planes (since the URL navigator is always below the toolbar). Maybe we could live with that though?

One plane for history-related navigation (back, forward), and one plane for navigation related to directory hierarchy (up, breadcrumb). Seems even more logical to me than grouping back/forward/up.


Let's wait until @elvisangelaccio has had time to comment again on the matter.

In fact, if we integrated the Up button into the KURLNavigator widget, it would solve some issues automatically (e.g. lack of up button in Gwenview). I could see some people complaining about it though, because then the navigation buttons would be in two different vertical planes (since the URL navigator is always below the toolbar). Maybe we could live with that though?

One plane for history-related navigation (back, forward), and one plane for navigation related to directory hierarchy (up, breadcrumb). Seems even more logical to me than grouping back/forward/up.


Let's wait until @elvisangelaccio has had time to comment again on the matter.

Yeah, I could definitely get behind it.

But Detailed View and Detailed Tree View are two different things, no? (I'm not even sure Windows supports the latter)

That's correct, Windows does not support the latter. In D12077 the button was added (sadly Nate thought it was enough to ask on IRC and Telegram regarding my suggestion to wait for one extra approval…), where we used the Tree variant for the more detailed view.

We could backtrack on that and use the non-tree variant, but personally I find it quite fitting for this mode to also allow expanding folders without navigating there, as it might allow to find things faster when not having to go back. Admittedly it adds some amount of visual noise.

Thoughts?

FWIW I also disagree with D12077. I don't see why we should show only two buttons (for short and detailed tree view), when we have four view modes.

FWIW I also disagree with D12077. I don't see why we should show only two buttons (for short and detailed tree view), when we have four view modes.

Because IMHO only two of them actually make sense the file dialogs. KDirOperator is flexible by design, and there is no reason to expose all of its functionality. For example Tree View is completely pointless in the file dialogs, because we have enough horizontal space to show the superior Detailed Tree View instead.

Detailed View and Detailed Tree View differ only in that the latter allows the folders to be expanded. I'm honestly fine with either one being featured as one of our two toolbar buttons but I don't think it makes sense to have them both visible as toolbar buttons given the very small differences between them. At one point I think @rkflx proposed collapsing them into a single mode with a checkbox for "allow expansion", as Dolphin has. I would be in favor of this if it's technically feasible.

rkflx resigned from this revision.Aug 24 2018, 10:46 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald TranscriptAug 24 2018, 10:46 PM
ngraham updated this revision to Diff 54303.Mar 19 2019, 11:44 AM

Rebase (I still think this makes sense)

ndavis added a subscriber: ndavis.Mar 26 2019, 8:02 PM

+1

Navigation is so much faster in tree view. I think navigation speed is what matters most of the time when people are selecting files or locations.

ngraham retitled this revision from Show Detailed Tree View by default to [KDirOperator] Show Detailed Tree View by default.Sat, Mar 30, 8:17 PM
This revision was not accepted when it landed; it landed in state Needs Review.Sat, Mar 30, 8:19 PM
This revision was automatically updated to reflect the committed changes.