SUMMARY I noticed after updating to KDE Gear 22.03.80 that now the whole line in detail mode is "responsive". By responsive I mean that you can click anywhere across the line (and not just on top of the folder itself). Although I can understand the reasoning behind this change (probably to make it easier for touch screens, or to select directories with short names), it does make some other common tasks more difficult. For example, now it is not possible to deselect everything by clicking anywhere in the empty space. I think the only option now it to use the keyboard. I can imagine some users that work mostly with the mouse annoyed by this change. Another example, drag and drop files to the open folder is now more also more difficult. Before you could drop the files anywhere in the lines and files would stay in the same directory. Using Ark, for example, to extract files inside some directory, you had to drop on top of that directory. Now dropping anywhere on the same line of the directory will do the trick. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.17.1-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2
> For example, now it is not possible to deselect everything by clicking anywhere in the empty space. > I think the only option now it to use the keyboard. I can imagine some users that work mostly with > the mouse annoyed by this change. In fact we tried our best to specifically handle this case, and there is some whitespace to the left of the icons that you can click on. It's not as large as the whole white area of the view, but it is still there. This area can be used for dragging files too. However for the drag use case, it is quite small indeed, and I can see how it's now difficult to drag something into the currently-viewed folder, rather than one of its child folders. I wonder if we should allow drags into the empty area of the folder as we used to, to try to improve that use case It seems like a legitimate usability regression.
(In reply to Nate Graham from comment #1) > > For example, now it is not possible to deselect everything by clicking anywhere in the empty space. > > I think the only option now it to use the keyboard. I can imagine some users that work mostly with > > the mouse annoyed by this change. > In fact we tried our best to specifically handle this case, and there is > some whitespace to the left of the icons that you can click on. It's not as > large as the whole white area of the view, but it is still there. This area > can be used for dragging files too. However for the drag use case, it is > quite small indeed, and I can see how it's now difficult to drag something > into the currently-viewed folder, rather than one of its child folders. Oh, that's right! I only realize that now. So I guess we can agree it's not very intuitive. Although now after you told me this I'm annoyed by the "empty" space on the left and I don't know how I didn't see it before hahaha > I wonder if we should allow drags into the empty area of the folder as we > used to, to try to improve that use case It seems like a legitimate > usability regression. Is the discussion open in gitlab? If so, can you share me the link. Maybe I can put there a few screenshot/videos with the issues I identified after this change. Thanks, Iyán
We can discuss it here.
Okay, so after a few days trying the new Dolphin, I'm still not used to this change. It's even hard to navigate in the "one click opens folders" mode. I also find the leading column padding confusing and ineffective. I can think of two possible solutions: 1. Add one option to choose the behavior, so users can go back to previous behavior. Maybe it would make sense to only use this new mode in "tablet mode" and leave it as it is in "normal" mode. 2. Allow to configure the position of the "column padding". For me (and most users), I think it would be more intuitive and easy to use to have that column between the name column and any additional ones (size, type, modifed, etc.). In this way, you benefit more homogeneous areas to select folders (no matter the name length), but you still have plenty of area to unselect with click, drag and drop, etc. What do you think?
Created attachment 148030 [details] alternative padding column (Annotate tool of Spectacle is just awesome!) Okay, so here is what I mean with solution 2. Hope it's clear.
Created attachment 148035 [details] screenshot with expandable folders option enabled By the way, the padding column is broken when the view is configured so that folders are expandable.
>Oh, that's right! I only realize that now. So I guess we can agree it's not very intuitive. >Although now after you told me this I'm annoyed by the "empty" space on the left >and I don't know how I didn't see it before hahaha In the 22.03.80 Beta version you tested, the padding was way narrower and not resizable. You might have had a better time if you hadn't been affected by a regressions causing this. The regression has been fixed (through a revert) for 22.03.90. >By the way, the padding column is broken when the view is configured so that folders are expandable. I believe this is fixed in the Release Candidate 22.03.90 already by the same revert mentioned above. >1. Add one option to choose the behavior, so users can go back to previous behavior. >Maybe it would make sense to only use this new mode in "tablet mode" and leave it as it is in "normal" mode. We have mapped out the required differences in usage of the new behaviour compared to the old and came to the conclusion that the biggest downside of the new behaviour is that users will have to come to terms with the changed click behaviour. This is a disruption that I understand some users will be upset about but there are still ways to do everything with similar efficiency as before. That's why having an option for this which then has to be maintained indefinitely was rejected. >2. Allow to configure the position of the "column padding". >For me (and most users), I think it would be more intuitive and easy to use to have >that column between the name column and any additional ones (size, type, modifed, etc.). >In this way, you benefit more homogeneous areas to select folders (no matter the name length), >but you still have plenty of area to unselect with click, drag and drop, etc. This seems quite unintuitive to me since one would now have an area that can't be used to click a file/folder in between areas that can be used to click them. Having the area to deselect at the side leads to a clear separation of spaces and responsibilities. I might have misunderstood you if you were meaning to say that the selection area should span the whole name column. In any case I created a merge request to resolve this bug report that also adds padding to the right end of the view. This has a number of benefits: - The right margin is more discoverable since the item highlight ends right before the padding column - Less mouse travel time to reach either of the areas - More than double the likelihood of users figuring out the advantages of these padding areas for deselecting or dropping - More visual symmetry Link to MR: https://invent.kde.org/system/dolphin/-/merge_requests/374
Thanks for the detailed explanation Felix. I will go ahead and comment directly on the MR.
Git commit 3bf471e02a440bd008d69c5939b7c5bf2c03df54 by Felix Ernst. Committed on 08/04/2022 at 09:44. Pushed by felixernst into branch 'release/22.04'. Add symmetric padding on right side of details view There have been some reports that users were unable to figure out that the padding on the left of the left-most "name" column can be used for deselecting or for dropping file items. All of these reports were by people using a Dolphin version in which that padding was way too narrow because of a regression (that has since been fixed). Nonetheless this highlights the potential problem that some users might be unable to notice/figure out the usefulness of the left padding. This commit adds a similar area on the right side of the view when the column widths are set automatically by Dolphin. The width of the right padding column mirrors the width of the left padding column when sized automatically. Both can manually be hidden or resized similarly to resizing other columns. There are various usability advantages to having this padding by default on both sides of the view and not only on the left: - The right margin is more discoverable since the item highlight ends right before the padding column - Less mouse travel time to reach either of the areas - More than double the likelihood of users figuring out the advantages of these padding areas for deselecting or dropping - More visual symmetry I had suggested also having this kind of right padding even before the initial implementation of the left padding. The contributor implementing it was in favour of it. It only wasn't implemented because the contributor said it was impossible without a lot of work. Turns out adding two characters at the right position seems to suffice in most ways. This commit does not contain the string change of renaming "Leading Column Padding" to "Column Padding" (since it changes two paddings now) to not infringe on the string freeze. M +3 -1 src/kitemviews/kitemlistview.cpp https://invent.kde.org/system/dolphin/commit/3bf471e02a440bd008d69c5939b7c5bf2c03df54
Feel free to re-open this bug report or create a new more targeted one if you still see issues with the more up to date version.
I confirm that I got used to this change after the last fix. I still think that the padding on the edges looks a bit weird and I look forward for future changes, but overall I think it's a nice improvement, specially for touch screens.
>I confirm that I got used to this change after the last fix. Thanks for confirming >I still think that the padding on the edges looks a bit weird and I look forward for future changes I'll keep that feedback in mind.
*** Bug 453528 has been marked as a duplicate of this bug. ***