https://bugs.kde.org/show_bug.cgi?id=453700
--- Comment #33 from Felix Ernst <fe.a.er...@gmail.com> --- (In reply to Mathias from comment #31) > I've been using 1) single-click and 2) split screens in 3) detailed list > view for ages, It seems like people with this combination are disrupted the most by the full row activation area. From what I have seen so far, most of the remaining strongly negative feedback to this change is from people in this user group. The problem is mostly about switching the active view. Before the full row highlight change, switching the active view by mouse was done by clicking not-directly-on-an-item which also cleared the selection. Now one can only switch the active view by either clicking the resizable padding on the sides or by drawing a small selection rectangle to the right of a file name. I agree that this requires a bit more effort. However it is debatable if it is unreasonable to expect users to click the side padding area and to resize it if clicking it seems to require too much effort. I wonder if there is another way in which we could make switching the active view easy that wouldn't get tripped up by the full row highlight. I guess not even the setting to switch the active view by using the "tab" key would be a complete solution because it also requires users to get used to it and isn't a great default for blind users. It would be best of course if we could find a solution that doesn't require any user to change a setting at all. Consuming the first click on an inactive view just to activate it but not to activate clicked items/rows might also potentially be unintuitive. Double-click users don't seem to mind this though. Ideas welcome. Having a setting to turn off full row highlight just because we can't figure out how to make switching the active pane comfortable would be a bit paneful. I am not really considering the unselecting of items as a big issue anymore because users unselect way less than they activate items so the usability benefit of having larger click areas for activation more than evens out the drawback of unselecting requiring more effort. This is true to me even if I take the initial learning curve into account. > and I use the navigation buttons (up and back) Clicking "Up" can be replaced by clicking the enclosing folder in the location bar but I guess opensuse has the "Up" button by default for a reason. It would be better if users didn't need to change their ways too much. I always click the "Back" button on my mouse to go "Back" without having to change the active view first. But not everyone does this or has such mouse side buttons so changing the active view first is necessary for many users. > or the mouse controls a lot to navigate through my folder structure. Not quite sure what you mean. Mouse controls work without changing the active view first so this shouldn't have become any more difficult. Actually it should be easier because the click target for opening a folder has increased. @Satyam: Not sure if you are aware, but most of the issues you have pointed out in comment #25 have already been addressed. Cutting and pasting has been fixed to work pretty much as before. The bug about tooltips is tracked separately and can be fixed separately of this bug report. Please don't compare KDE to Microsoft and Apple as long as the regressions happen because we are fixing popular bugs. Sensationalism doesn't help here. -- You are receiving this mail because: You are watching all bug changes.