Figuring out if we need an option for the old details view without full row highlighting
Related bug report: https://bugs.kde.org/show_bug.cgi?id=453700
I believe I have fixed all the glaring issues some users originally had with the new full row highlight behaviour (aside from bug 455645). There is one way to use Dolphin though that seems to still be disrupted by the full row highlight change. Here is a picture displaying such a usage scenario:
The advantages of this configuration are explained in the bug report by Mathias like this:
In this setup you have the most information per square inch, control, speed and flexibility in sorting etc. It is not only about the probably amusing fact that people like me are used to a Midnight (or Norton;)) Commander style, detailed-listed, split view since the days before graphical UIs became common. It is about productivity. Same thing with single click: Twice as fast ;) I sincerely hope KDE and Dolphin keeps us in mind in the development.
The problem is mostly about switching the active view which might be necessary to use e.g. the "Up" action in the toolbar. Users like this don't want to add padding to the sides which can be clicked to switch the active view. While they could switch the active view without activating an item also by drawing a small selection rectangle or by right-clicking, both of those methods are unintuitive and somewhat cumbersome.
I should also mention that our original concern that unselecting is too difficult doesn't seem to be as big of an issue because unselecting isn't as necessary and frequent as changing the active view.
So I guess my question is this: Do we add an off-by-default option that makes it so details view works as it used to? Is there some other way to make these users happy? (My failed pondering yielded the following ideas that IMO wouldn't really resolve the issue: 1. "make a new action to switch active tab with a nice default keyboard shortcut"; 2. "have the first click in the view always be consumed so it only changes the active view")
There was/is !345 (closed) which adds this option and shows that the code currently needed for this is manageable but this doesn't change that this is again one more configuration that needs to be tested and maintained.
I'll tag some of you that might have an opinion on this. Please unsubscribe from this issue if you didn't want to be added. @tomlin @meven @georgefb @derek @ngraham @ivan