[dolphin] [Bug 453700] dolphin in detailed view open files and folders also if I click elsewhere on the line not only on the filename

Felix Ernst bugzilla_noreply at kde.org
Sat Jul 30 01:30:21 BST 2022


https://bugs.kde.org/show_bug.cgi?id=453700

--- Comment #33 from Felix Ernst <fe.a.ernst at 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 on the CC list for the bug.


More information about the kfm-devel mailing list