Bug 453700

This is the intentional new approach in Dolphin. It was done to implement a very long-standing request: Bug 181437.

I know it's a change, but I think you might like it if you give it a chance.

(In reply to Nate Graham from comment #1)
> This is the intentional new approach in Dolphin. It was done to implement a
> very long-standing request: Bug 181437.
> 
> I know it's a change, but I think you might like it if you give it a chance.

I gave a chance for about one month, I didnt noticed that it was changed until I made a lot of errors clicking on files and dropping files in wrong places and cannot have the correct right click menu', it's an annoying behaviour becouse you have to give too much attention to where you click and drop and it is too easy to open a file unintentionally by clicking somewhere to the right of the file name.
and also when you drag a file you drop it in the row and it goes in the activated folder instead ov in the folder and also when you rightclick the menu depends if the row is activated or not, I really prefere that this behaviour be an option as KDE traditional approach and not to have no choice

*** Bug 453528 has been marked as a duplicate of this bug. ***

I will agree that drag-and-drop is regressed because it's now much harder to drop into the view, rather than a folder within it. That seems like a legitimate issue we can improve upon.

Can you please open a new bug report about just that, and we can look into it. Thanks!

The change that is causing these issues is in my opinion a bad design decision.

I can no longer copy or cut a file and paste it using the context menu unless the dolphin window contains empty space below the last file/directory. Where the window is filled with a list of files or directories, the context menu when clicked on a line that contains a file does not contain an option to paste the file. When clicked on a line that contains a directory the option to paste is there but the file is pasted into the directory on the clicked line instead of the directory being viewed.

I can no longer drag and drop a file into an empty space in a dolphin window that is filled with a list of directories. The file will be dropped into the directory of the line where the mouse button is released instead of into the directory being viewed. I have misplaced files several times because of this until I realised what was happening.

I can no longer click on an empty space after a file name to deselect a file. Doing so opens the file or enters the directory. More attention needs to be paid to click to the left of the file or directory name to deselect it.

I can no longer click on the empty space after a file or directory name to select the left or right pane when in split view. Doing so opens the file or enters the directory on the line clicked.

All these in my opinion being regressions from previous versions making dolphin annoying and more difficult to use.

I found you can click on the empty space right of the file name and drag a few pixels, it creates a selection rectangle and it will select that file (sure it requires some additional effort). You can also keep CTRL keyboard key before clicking on the file (not required when dragging to select several files).

I think one great opportunity here to improve the selection mechanism of dolphin would be, while keeping the full line highlight introduced recently, to let only a click on the Name column to trigger the Open action, while the optional columns of the Detail view (such as: size, timestamp) would act only for selection.

That's exactly how it was before. :) And it was unpopular.

Of course, this seems to be unpopular too, among a different group of people. Sometimes you can't win. UX design is hard.

If you agree there are two groups of people that cannot be simultaneously pleased, would that be enough justify making it a configurable feature?

It seems user group complaining right now are single-click users. Since single-click is supported by Plasma, it makes sense for the applications to offer appropriate options when relevant.

That's the nuclear option. I'd prefer if we did some more UI design work first to find something that works out-of-the-box for both groups automatically. Only if that fails would it make sense to add a user-configurable option IMO.

Maybe this whole feature itself should be automatically turned on or off based on whether you're using single-click or double-click.

>I can no longer copy or cut a file and paste it using the context menu
>unless the dolphin window contains empty space below the last file/directory.
>Where the window is filled with a list of files or directories, the context menu
>when clicked on a line that contains a file does not contain an option to paste
>the file. When clicked on a line that contains a directory the option to paste is
>there but the file is pasted into the directory on the clicked line instead of the
>directory being viewed.

This part is not a design decision but a bug. I opened a merge request that should fix this: https://invent.kde.org/system/dolphin/-/merge_requests/399 – Thanks for letting us know.

--------------------------

I agree with most of what Nate said. Drag and Drop might be something we should change so dropping on top of an empty row drops the item on the view area and only dropping on top of a folder icon or name would drop inside the folder. This could be made clear by clearly highlighting the folder that receives the files.

I am also not sure yet if having a setting for this is the right decision. I am not aware of a downside that seems exclusive to single-click mode but it is of course true that clicking a row used to deselect items and now counts as a click on the item which should be similarly unexpected for single-click users and double-click users (but the result is worse for single-click users). I am testing the potential regressions myself currently by exclusively using Details view mode in single-click mode and even hiding all extra side padding.

This certainly leads to slightly different usage patterns because I can hardly use the side padding for drag and drop or deselecting. The most prominent change in behaviour for me is that I don't bother clearing the selection anymore if only one item is selected. There is also no reason for me to ever clear the selection other than a feeling that one doesn't want a file to be selected.

>I found you can click on the empty space right of the file name and drag a few pixels,
>it creates a selection rectangle and it will select that file (sure it requires some additional effort).

This was also the old way of selecting singular files in single-click mode so this hasn't changed.

> You can also keep CTRL keyboard key before clicking on the file
>(not required when dragging to select several files).

One used to need to Ctrl+click the file's icon or text to select it. Now Ctrl+clicking the same row works.

I also strongly dislike the new behavior. Apart from annoying me like I didn't know was even possible, it makes some things a lot more difficult. The first thing that comes to mind is trying to move something (drag-n-drop) into the root of a directory with only subfolders in view, which is damn-near (or maybe even literally?) impossible. Getting the desired right-click context menu as mentioned above as well.

Also, I tend to want to actually _deselect_ things, which is admittedly non-functional, but very much harder to pull of now.

The old behavior was considered unpopular (apparently) based on the existence of a feature request. Well, this behavior is also unpopular as evidenced by this bug report (as well as comments on Bug 453528 and Bug 453528). Who's to say which is more unpopular, have things improved or worsened? A revert would cause Bug 181437 to be reopened (though I personally wouldn't mind). This so obviously just needs an option in the settings.

>Drag and Drop might be something we should change so dropping on top
>of an empty row drops the item on the view area and only dropping on top
>of a folder icon or name would drop inside the folder. This could be made
>clear by clearly highlighting the folder that receives the files.

https://invent.kde.org/system/dolphin/-/merge_requests/401

*** Bug 453198 has been marked as a duplicate of this bug. ***

The biggest issue is that it's very unintuitive to have no empty space in the view that doesn't cause an action on drop or click.

For example, I used to click into the empty space to select the view (in split mode) for toolbar commands or to sync the terminal directory. Now, after some adjustment period I found that I can click the scroll bar if the directory list is full.

Similarly drag&drop works same as before by dropping on the column headers instead of directly into the pane. It works and I'm starting to get used to it, but it sure as hell isn't intuitive. It took me a few seconds of trial and error to find some surface I can use to get my file where it should.

Adding to the unintuitiveness of these weird usage patterns that this behavior encourages, there is also the inconsistency. For example, when clicking to the left of a file, an unfolded directory tree, or exactly between the arrows, that space still seems to have the old behavior where a click doesn't select the line. I've caught myself a few times unfolding a directory just to have a reliable space to click into.

So while I would much prefer the old behavior back, I would also happily settle for a consistent, less unintuitive compromise.

*** Bug 455110 has been marked as a duplicate of this bug. ***

Git commit 5ebf2065d525160a29f1d7aeef41541c6033bccf by Felix Ernst.
Committed on 16/06/2022 at 09:11.
Pushed by felixernst into branch 'master'.

Don't consider drops on a row as drops on the row's item

Since d3839617193e92463806580699caa595c892b8a6 in details view mode
clicking anywhere within the row is considered a click on the item.
That commit also changed it so that dropping files anywhere inside
a row would make it so the files are received by the folder of that
row.

This commit reverts the drop behaviour to be identical to the old
one.

I am having trouble explaining why this is better because one can
look at it in different ways. Bottom line is that one doesn't
really feel like one is dropping files inside a folder unless the
mouse cursor is actually directly above a folder's icon or name.

Another argument is that it is normal behaviour to just throw files
onto an application and the files then being opened by it.
Having potentially large parts of the view area covered by the rows
of folders means that there has to be more of a conscious effort to
not drop the files inside one of the folders by accident while with
this commit one has to aim precisely onto a folder to do it
intentionally.

M  +22   -2    src/kitemviews/kitemlistcontroller.cpp
M  +9    -0    src/kitemviews/kitemlistcontroller.h

https://invent.kde.org/system/dolphin/commit/5ebf2065d525160a29f1d7aeef41541c6033bccf

being a single klicker for years, i'm not a big fan of the new "use the full row" behavior.
and actualy switched to double clicking experimental wise. said that...

using the full row as a drop zone at least is/was consistent! now this feels weird IMHO.

as other posters mentioned above, it is practically impossible to deselect any item with
a dolphin window totally crowded with items, and there no space left, that belongs to the
current displayed folder. if single clicking or double, no difference.

what about de-selecting items with a second (not double) click on an item?

In addition, this "whole row selection" now makes tooltips of files very annoying.
I just want to see the details (in a tooltip) when I actually point at a file (name, that is).
Now it's impossible to NOT point at something.

Just throwing in my vote for a configuration option for this. I tried to get used to this new behaviour, but it's still annoying me and I'm a double-click user.

(In reply to Johannes Schmidt from comment #14)
> Adding to the unintuitiveness of these weird usage patterns that this
> behavior encourages, there is also the inconsistency. For example, when
> clicking to the left of a file, an unfolded directory tree, or exactly
> between the arrows, that space still seems to have the old behavior where a
> click doesn't select the line. I've caught myself a few times unfolding a
> directory just to have a reliable space to click into.
> 
Yea, I went one step further and enabled "Leading Column Padding" so there is always empty space on the left to click on...

(In reply to Martin Koller from comment #18)
> In addition, this "whole row selection" now makes tooltips of files very
> annoying.
> I just want to see the details (in a tooltip) when I actually point at a
> file (name, that is).
> Now it's impossible to NOT point at something.

Please file a separate bug report for this. This is something we will want to fix no matter if there is going to be a configuration option for this or not.

(In reply to Dušan Dragić from comment #19)
> Just throwing in my vote for a configuration option for this. I tried to get
> used to this new behaviour, but it's still annoying me and I'm a
> double-click user.
> 
> […]
> Yea, I went one step further and enabled "Leading Column Padding" so there
> is always empty space on the left to click on...

We are still considering whether to add a configuration option for this or not. First of all I want to discourage people here to all write "I want a configuration option too!". Since Dolphin has many millions of users we can't base decisions solely on the quantity of feedback we get by advanced users able to find this bug tracker. Feedback saying what exactly doesn't work anymore for you would be better e.g. "I have trouble selecting files under <these circumstances>".

Unfortunately there were some usability bugs with the new behaviour and now we have some feedback of people wanting to opt out of all of the new behaviour and we can't be sure if that is mainly because of bugs that can be or were already fixed. (We also have feedback of people being happy with the new behaviour.)  For example the "Leading Column Padding" should have been enabled by default so there is always an area to deselect/click the background.

That being said, there shouldn't even be much of a need to use the padding area to click the background. As can be seen by my comments above, two bugs were already fixed that now allow a bigger drop area for files and a bug to right-clicking was also fixed. One reason to click the background/view area that seemed valid to me at first was for people using split view wanting to switch the active view. But then I couldn't find a reason to do that without also selecting a file because mouse navigation works normally without activating the view first.

So it seems to me like we need to unfortunately take a more long term approach towards deciding this. We'll monitor the feedback after 22.08 is released and then we'll see if there is a way to decide objectively if there is enough reason to take on the maintenance burden of having this as a configuration option. I am sorry if this isn't the immediate feedback some of you were hoping for.

(In reply to Felix Ernst from comment #20)
> (In reply to Martin Koller from comment #18)
> > In addition, this "whole row selection" now makes tooltips of files very
> > annoying.
> > I just want to see the details (in a tooltip) when I actually point at a
> > file (name, that is).
> > Now it's impossible to NOT point at something.
> 
> Please file a separate bug report for this. This is something we will want
> to fix no matter if there is going to be a configuration option for this or
> not.

Done. Bug #455645

The new behaviour caused a lot of frustration to me as a single clicker. But I'd like to suggest a compromise that avoids a configuration option and hopefully both sides can agree on. Let's start with some reasoning.

In my opintion, a clickable area should either uniquely belong to an item in the folder, or to the folder that contains the item.
* "belong to the item" means left click opens it, right click opens its context menu, dropping something on it means into it, click and hold drags the item, and hover opens the item's tooltip.
* "belong to the folder" means left click unselects selected items, right click opens the context menu, dropping means into this folder, and click and hold activates the rubber band selection.

Now we have an odd mixture: the entire row belongs to a list item if you click on it, but (apart from the name) it belongs to the folder if you use the rubber band, open the context menu or (with https://invent.kde.org/system/dolphin/-/merge_requests/401) if you drop something on it. This seems quite counterintuitive to me.

So here's my suggestion: Treat the space within the "Name" column as if it belongs to the item with all consequences (see above), but the space within all other columns (Size/Modified/Owner/...) as if it belongs to the folder.

That's basically what Ark does, but it's not immune to confusion of a different form. See Bug 426499.

As is described there, this is a matter of highlighting.

In Ark (I'm on 22.04.2), the entire line is clickable (and highlighted), but only the name is draggable, which is inconsistent in the described sense of space belonging to a specific object.

Following my suggestion, only the Name column should be clickable & draggable. And to indicate that, only that column should be highlighted (rule: highlight the area that "belongs" to the item). Downside: we loose the visual accentuation of the rest of the row. Thanks to the alternating background colours in Dolphin's details view I'd find this acceptable (there is also the suggestion of different highlighting styles/colours).

Of course in a perfect world all file listings in KDE applications would behave in the same way.

(In reply to Nate Graham from comment #1)
> This is the intentional new approach in Dolphin. It was done to implement a
> very long-standing request: Bug 181437.
> 
> I know it's a change, but I think you might like it if you give it a chance.

I see a logic of selecting the whole line, there was a case where you had to maneuver to select your file. but it turns out to be a severe regression of usability. Now the maneuvering has increased.  It takes away usability in unselecting files, in cutting and pasting, and in letting the tooltips get out of the way.  Instead of having all the non filename space to unselect files, copy or paste, or let tooltips hide I am forced to tediously navigate to a small area at the beginning of the line. This is a major increase in time and coordination. The useability and flow of working with dolphin just significantly decreased.

In dolphin 22.04.2, utilising the blank column on the left hand side of the window fixes all my issues.

- Deselecting files
- Clicking in the blank column to select a pane in split view
- Right-click to paste a file into the directory being viewed
- Right-click a directory in the list and select paste file to paste a file into that directory
- Drag and drop a file into the directory being viewed
- Drag and drop a file over a directory in the list to paste the file into that directory

(In reply to Richard Ullger from comment #26)
> In dolphin 22.04.2, utilising the blank column on the left hand side of the
> window fixes all my issues.
> 
> - Deselecting files
> - Clicking in the blank column to select a pane in split view
> - Right-click to paste a file into the directory being viewed
> - Right-click a directory in the list and select paste file to paste a file
> into that directory
> - Drag and drop a file into the directory being viewed
> - Drag and drop a file over a directory in the list to paste the file into
> that directory

There are two problems with that, it's clumsy having to maneuver to such a small area and it takes away precious filename real estate.

(In reply to Richard Ullger from comment #26)
> In dolphin 22.04.2, utilising the blank column on the left hand side of the
> window fixes all my issues.
> 
> - Deselecting files
> - Clicking in the blank column to select a pane in split view
> - Right-click to paste a file into the directory being viewed
> - Right-click a directory in the list and select paste file to paste a file
> into that directory
> - Drag and drop a file into the directory being viewed
> - Drag and drop a file over a directory in the list to paste the file into
> that directory

Yes, also if you use an empty column on the right, but it is still very unconfortable and as Satyam says it takes away precious filename and other informations like data or owner real estate.
another way that partially weaken the unconfortability is to set the systemsettings>window action>right clic to only activate and rise and to not pass the click, but it imply to change the universal behaviour to leftclick to a window to rise only

I complained when testing the beta, and I am considering the empty column workaround a joke.

I was a single-click user. Now I switched to double click.

*** Bug 454636 has been marked as a duplicate of this bug. ***

Another usage scenario that cries for making the old behaviour at least available as an option again:

I've been using 1) single-click and 2) split screens in 3) detailed list view for ages, and I use the navigation buttons (up and back) or the mouse controls a lot to navigate through my folder structure. And for doing that I need to change focus between the two split lists a lot. And I switch between the two lists by clicking in empty areas - the biggest ones are usually those after the filenames. The small empty column at the start is - too small.

So please make it an option if you don't like to revert to the old behaviour. Until this change Dolphin was such a great file manager.

(Switch to double-click is not an option, than I could have stayed with Windows 25 years ago  ;))

This update abandons the way dolphin has worked for the entirety of it's existence.  It's not true to make a change to a fundamental way something has functioned for many years and say that's fixing a bug.  This is not a bug fix, it's a reduction of function.  KDE introduced me to single click in 3.5. Turns out there's a major efficiency with it. Now you're abandoning my years of use in favor of an idea that it's a more correct way.  For years KDE has offered the most efficient work flow.  For the first time ever I'm finding myself being disrupted the way I'm used to by Microsoft and Apple.

(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.

(In reply to Felix Ernst from comment #33)
> (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. 

Full ack. And there's a pattern here I guess. 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. Because this is great software I am very thankful for.

> > and I use the navigation buttons (up and back)
> Clicking "Up" can be replaced by clicking the enclosing folder in the
> location bar 

Not if you are using an editable location bar, like me (but this is probably something where you could actually get me to change a behaviour, because it is only one click away to switch to a clickable folder hierarchy).

> 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.

In fact, I do have these side buttons under my thumb and use them a lot.
 
> > 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. 

I mean exactly the side button of the mouse you mentioned. And yes, I do not have to change the active view in this case because the mouse-back-button always affects the view pane that is under the cursor. Which is great and perfectly intuitive.
But still: on a laptop with a touchpad but without multi-button-mouse dolphin's back-button is still needed - along with an easy way to change the active view of a split screen.

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/467

Git commit 9478f1473006147c643c228793822b2eeb4b0606 by Felix Ernst, on behalf of Felix Ernst.
Committed on 27/10/2022 at 09:40.
Pushed by felixernst into branch 'master'.

Make details view mode's full row activation optional

In d3839617193e92463806580699caa595c892b8a6 the details view mode
was changed in a way that made the full row of an item the click
target instead of only having the item's icon and text be the
representative clickable area of an item.

This commit makes this new behaviour optional through a setting
which can be changed in Dolphin's settings dialog.

The explanation for introducing yet another setting in this case is
as follows:

While the introduced change is an improvement for many typical
workflows, there are some workflows for which this new behaviour
is problematic. Quite prominently a usage of Dolphin that tries
to maximise information density is made worse by the change because
now side padding is necessary to click the view's background. While
the side padding is and was optional, disabling it made switching
the active view in split view mode more difficult among other
things. For a more complete discussion about the issues, please
check out the bug report(s) and the discussion in Dolphin's gitlab
issue with number 34.

Co-authored-by: Ivan Čukić <ivan.cukic@kde.org>
FIXED-IN: 22.12

M  +6    -1    src/kitemviews/kstandarditemlistview.cpp
M  +2    -0    src/kitemviews/kstandarditemlistview.h
M  +1    -0    src/kitemviews/kstandarditemlistwidget.cpp
M  +4    -0    src/settings/dolphin_detailsmodesettings.kcfg
M  +22   -0    src/settings/viewmodes/viewsettingstab.cpp
M  +1    -0    src/settings/viewmodes/viewsettingstab.h
M  +6    -1    src/views/dolphinitemlistview.cpp
M  +3    -0    src/views/dolphinitemlistview.h

https://invent.kde.org/system/dolphin/commit/9478f1473006147c643c228793822b2eeb4b0606