Bug 424723

Didn't you get a confirmation dialog to see that you were moving two items to the trashcan?

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.

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

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?

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

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.

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.

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?

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.

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

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.

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

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

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 :) )

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.