Bug 424723 - When going back or up, underline the folder you just came from instead of selecting it
Summary: When going back or up, underline the folder you just came from instead of sel...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2020-07-27 21:02 UTC by Tom
Modified: 2024-08-29 11:47 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom 2020-07-27 21:02:22 UTC
Dolphin has a hard rule on what do to if you enter a folder from one of its subfolders. It selects the folder you 'came' from. This has UX problems, though as this is a bit random and allows people to lose their data.

STEPS TO REPRODUCE
1. Start dolphin, for instance from krunner typing 'Downloads'.
2. Press 'up'.
3. Notice that 'Downloads' is selected
4. An unsuspecting user might not notice and select a file in this dir by the 'plus' hover icon.
5. pressing 'delete' now moves to trash 2 items, while the user never selected the dir.


It seems that Dolphin by default always selects the one folder it came from, overruling any selection that was there before.

To work towards a solution I would like to invite you to try one more test:

1. open dolphin and select any directory
2. navigate 'up'.
3. press outside of all items in order to remove the selection.

Notice that at this point your folder you came from still has an underline. A simple 'return' will enter that dir again.

I would like to suggest that instead of selecting an item that Dolphin only sets the anchor. Or does an m_selectionManager->clearSelection(); after the current select.

This gives all users the benefits they currently have and this avoids the problem of unsuspecting users losing directories by deleting them because Dolphin auto selected the folder for them.
Comment 1 Christoph Feck 2020-08-17 17:23:10 UTC
Didn't you get a confirmation dialog to see that you were moving two items to the trashcan?
Comment 2 Justin Zobel 2020-11-02 07:36:19 UTC
Items are not lost, they are in the trash which has to be manually emptied, it is not automatically emptied.

If the user notices the folder gone, they can even Undo the action.

If the default action was permanently delete I could see how this would be a very frustrating situation.
Comment 3 Tom 2020-11-02 18:30:16 UTC
> Didn't you get a confirmation dialog to see that you were moving two items to the trashcan?

This UX bug is about a folder too many being selected, and while I agree that a user **may** notice an extra item in the popup, this is not really relevant to the bug report as that is at best a band-aid. Not a solution.
If you explicitly delete something, you won't read the whole dialog. I've always found that dialog a 'cover-your-ass' dialog protecting the developers while not providing any support to the vast majority of users.

> Items are not lost, they are in the trash which has to be manually emptied, it is not automatically emptied.

Unless you press shift-delete, which users learn because normal delete has plenty of UX issues. For instance a new directory is created on a USB pen and you can share those super private items you thought were gone anyway. Or (as previously) items are copied from slow media.
The trashcan has a long list of UX issues, when they hit the "you need to empty it" dialog more than once, they will learn to avoid it.

As the first commentor, this reply also hopes that a band-aid is enough, which surprises me as I'm pretty sure that a developer that is familiar with this code can fix it in 2 hours tops.

So maybe commenters can review the suggested solution and comment on how their UX would improve (or not) should it be implemented.
Comment 4 Nate Graham 2020-11-02 20:59:20 UTC
Every action is undoable, and all potentially destructive actions show a confirmation dialog. Even moving items to the trash shows a confirmation dialog.

Now, yes, the user may not notice what they have selected. They may not read the dialogs. They may not know how to undo. They may bypass the trash and delete directly for whatever reason.

But eventually you have to treat the user as an adult and expect that they take responsibility for their actions in an environment where there are already reasonable safeguards. This is especially true for users who use the dangerous "delete immediately" action. If you use that, you ought to know what you're doing and be paying attention. There's a reason why it's not the default deletion action and why the trash paradigm exists. If you deliberately bypass the safeguards and do something potentially dangerous, it's on you to make sure that you don't blow anything up.

If we add more safeguards, people will start to complain that the warnings slow them down. If we remove the "select previous folder when going back" behavior, people will complain about that, because it will interfere with their ability to use keyboard navigation.

The one thing I think we could do here is to make undo more obvious by displaying a little tiny (emphasis on tiny) time-limited notification inside the UI with an undo button in it after move, copy, deletion (etc.) actions. A lot of mobile apps do this to increase the discoverability of their undo actions for deletion in particular, and I think it's a good UI innovation.

Do you think that would help?
Comment 5 Tom 2020-11-02 23:52:18 UTC
>  If we remove the "select previous folder when going back" behavior,
> people will complain about that, because it will interfere with their 
> ability to use keyboard navigation.

My suggestion is to avoid selecting something, which would lead to the user being able to delete it.

Instead you set the anchor to the directory you just left. Which solves the problem of keyboard navigation without the downside of giving the user enough rope to hang him/herself.

To see what I mean with "set the anchor" you can follow the following steps:


1. open dolphin and select your Desktop icon, entering it.
2. Click on the word "Home" in the locator to go back up.
3. Select nothing by clicking between folders.

Notice that at this point your folder you came from (Desktop) still has an underline. Keyboard navigation is kept in that way, pressing 'return' enters it, arrows move the active item (and select them) as expected.

That would solve the core of the issue:
* dolphin doesn't magically select items.
* users don't lose any abilities, like keyboard navigation.
Comment 6 Nate Graham 2020-11-03 00:09:57 UTC
Interesting idea. I'll admit I don't really like Dolphin's "anchor" as you put it (I don't even know what to call it) but I'll admit that your suggestion would solve the problem.
Comment 7 Tom 2020-11-05 19:22:15 UTC
The concept of "Anchor" is copied from some Qt APIs. The QTextCursor being the one I know best (since I maintained qtextdocument for some time).

The idea is that the 'view' model has an anchor at one point and then if you shift-click a couple of items to the right, you select all items between the anchor and the one you clicked.
So the anchor is the current item, which is not selected. And it works as an anchor for selecting things.

see QTextCursor::anchor()

If you map this to QItemSelectionModel it doesn't have a name specifically. It (AFAIK) just means that you have a currentIndex, but you have no selection.

Hope this helps.
Comment 8 Tom 2020-11-06 14:54:37 UTC
Justin Zobel <justin.zobel@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |wishlist


I always disliked how software developers consider UX-bugs "wishlist" level. Its my wish that Dolphin doesn't automagically select items for me. I consider the current behavior a bug, which actually managed to cause data-loss.

* unpredictable behavior
* 100% of people will hit this behavior
* possible dataloss as a result

How does "wishlist" level follow?
Comment 9 Nate Graham 2020-11-06 14:57:49 UTC
It's sometimes a fine line, but the distinction is mostly academic from a KDE perspective. We don't intentionally de-prioritize wishlist items compared to bugs.
Comment 10 Justin Zobel 2020-11-07 01:55:10 UTC
(In reply to Tom from comment #8)
> Justin Zobel <justin.zobel@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Severity|normal                      |wishlist
> 
> 
> I always disliked how software developers consider UX-bugs "wishlist" level.
> Its my wish that Dolphin doesn't automagically select items for me. I
> consider the current behavior a bug, which actually managed to cause
> data-loss.
> 
> * unpredictable behavior
> * 100% of people will hit this behavior
> * possible dataloss as a result
> 
> How does "wishlist" level follow?

As Nate mentioned there is not distinguished level between bugs and wishlist items.

As for data loss, it's a potential factor in using almost any piece of software. This is why backup regimes are so important. I backup my home folder every 3 hours while my PC is on for this reason.
Comment 11 locutusofborg 2023-06-14 11:20:59 UTC
If as stated that one launches Dolphin then selects downloads, then select items in it to delete the parent folder should not be being deleted. I should be automatically unselected. If this behavior does exsist in Dolphin then there is something wrong.
Comment 12 Bug Janitor Service 2024-04-20 11:42:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/766
Comment 13 Felix Ernst 2024-05-18 22:18:17 UTC
Git commit 122fee5625f0285ec4ebda79162c72390989eb2a by Felix Ernst.
Committed on 18/05/2024 at 22:18.
Pushed by felixernst into branch 'master'.

Avoid implicitly selecting items

Items should only be selected if the user wants to act on them.
However, previous to this commit we sometimes selected items even
when there is no reason to assume that the user would like to act
on them. Such selections are dangerous because they make it more
likely that the user manipulates items by accident which they
never even explicitly selected.

Example: The "Up" action is used to navigate to the parent folder.
This will implicitly select the folder one emerged from after
opening the parent folder, so just one accidental press of the
Delete key will lead to data loss if the press goes unnoticed. This
scenario would have been avoided if no folder had been selected
automatically.

The above example becomes even more dangerous if the user is acting
with elevated privileges.

The following implicit selections of items are being removed:
- Selecting items that are being activated
- Selecting folders one emerges from

Even though these items will no longer be selected after these
actions, they will still be marked as current.

The only downside I see is that our indication of which item is "current" is a lot weaker than the selection highlight, so it might be more difficult to spot which folder one has emerged from. However, this could be counter-acted with some other temporary indication if this really turns out to be a problem.

The only downside I see is that our indication of which item is
"current" is a lot weaker than the selection highlight, so it might be
more difficult to spot which folder one has emerged from. However, this
could be counter-acted with some other temporary indication if this
really turns out to be a problem.

M  +2    -1    src/dolphinviewcontainer.cpp
M  +17   -4    src/kitemviews/kitemlistcontroller.cpp
M  +43   -4    src/tests/dolphinmainwindowtest.cpp
M  +7    -0    src/tests/kitemlistcontrollertest.cpp

https://invent.kde.org/system/dolphin/-/commit/122fee5625f0285ec4ebda79162c72390989eb2a
Comment 14 Peter Ped Helcmanovsky 2024-08-28 08:27:42 UTC
I don't agree with this change, for me it feels wrong and breaks some of my habits how I did stuff in Dolphin before.
(just factual statement, I don't expect any action to happen just because I personally don't like something, but in case you wonder if there is someone who liked previous behaviour more = yes, at least me :) )
Comment 15 smow 2024-08-29 11:47:36 UTC
I heavily disagree with this change, especially "double clicking on an item (with double-click to activate) already selected will de-select the item" not being a downside. Personally, implicit selection never bothered me - in fact it simplified the workflow, but now it breaks my habit of using Dolphin.

Something like a setting to revert it back would be really welcome.