Bug 492404

Confirmed:
1. Open configure dialog
2. Select View -> Details
3. Open files and folders -> By clicking on icon or name

Open folder without selecting it (just single or double click) over the name or icon, click back button, folder isn't selected

For me it's "By clicking everywhere on the row" so I think the problem exists no matter which option is being selected:

https://i.imgur.com/djLsMoT.png

https://invent.kde.org/system/dolphin/-/commit/122fee5625f0285ec4ebda79162c72390989eb2a

I think it's logically to expect entered folder to be selected, so when you return, view will navigate you to the parent. Also when open file is the same, it needs to be selected. So patch should be if a folder or file is request to be open, it should be selected as well.

(In reply to mozo from comment #0)
> EXPECTED RESULT
> The folder should be selected in order to know which folder we're exiting
> from.

The folder is still supposed to be marked with an underline, which would make it clear which folder one is exiting from. Does that not happen for you?

If this is about the underline not being as visible as a selection, that is something we want to improve on in the future. That part is being discussed in https://invent.kde.org/system/dolphin/-/issues/53.

(In reply to Felix Ernst from comment #5)
> (In reply to mozo from comment #0)
> > EXPECTED RESULT
> > The folder should be selected in order to know which folder we're exiting
> > from.
> 
> The folder is still supposed to be marked with an underline, which would
> make it clear which folder one is exiting from. Does that not happen for you?
> 
> If this is about the underline not being as visible as a selection, that is
> something we want to improve on in the future. That part is being discussed
> in https://invent.kde.org/system/dolphin/-/issues/53.

For me it's underlined but it's hard to see. And this change ruin my workflow entirely for I'm working with many folders. Why should we invent the weel and broke working things? Every single file manager is working this way but Dolphin...

(In reply to mozo from comment #6)
> And this change ruin my workflow entirely for I'm working with many folders.

Would you please elaborate in what way this change ruins your workflow? Maybe give an example of a typical chain of actions that is now made considerably harder by this change? 

> Why should we invent the weel and broke working things?

The change was implemented so that users who are bad with computers are less likely to delete files by accident. There was a bug report about this and I expect this to happen somewhat regularly because it only requires a single wrong key press or a cat walking over the keyboard to secretly delete a file. It is in the nature of this though that users might not notice when this happens and are therefore unlikely to report this as a problem with Dolphin when it happens.

(In reply to Felix Ernst from comment #7)
> (In reply to mozo from comment #6)
> > And this change ruin my workflow entirely for I'm working with many folders.
> 
> Would you please elaborate in what way this change ruins your workflow?
> Maybe give an example of a typical chain of actions that is now made
> considerably harder by this change? 

Example - I have 300 folders and 1000 files in one folder. When I made changes to one of the folder, I'm exiting it with Up and drag and drop this folder. Now I can't find it because of the many folders and it takes me considerable time to find the folder. And when you have to seek a folder 300 times a day, it's deadly and you begin to wondering why someone should ruin your favorite file manager.

> 
> > Why should we invent the weel and broke working things?
> 
> The change was implemented so that users who are bad with computers are less
> likely to delete files by accident. There was a bug report about this and I
> expect this to happen somewhat regularly because it only requires a single
> wrong key press or a cat walking over the keyboard to secretly delete a
> file. It is in the nature of this though that users might not notice when
> this happens and are therefore unlikely to report this as a problem with
> Dolphin when it happens.

Here's not a kindergarten. This feature is wrong by design. I can give you hundresds of dangerous PC situations and we have to rewrite the entire DE because of them? It's ridiculous.

(In reply to mozo from comment #8)
> (In reply to Felix Ernst from comment #7)
> > Would you please elaborate in what way this change ruins your workflow?
> 
> Example - I have 300 folders and 1000 files in one folder. When I made
> changes to one of the folder, I'm exiting it with Up and drag and drop this
> folder. Now I can't find it because of the many folders and it takes me
> considerable time to find the folder. And when you have to seek a folder 300
> times a day, it's deadly

Okay, so this bug report is indeed mostly about making sure that the highlight is more visible then. Thanks for confirming!

> Here's not a kindergarten. This feature is wrong by design. I can give you
> hundresds of dangerous PC situations and we have to rewrite the entire DE
> because of them? It's ridiculous.

Dolphin should indeed be usable both for children as well as for cognitively, motorically, or visually impaired users, if possible. So there are trade-offs between various target user groups that need to be considered. I definitely want Dolphin to work great for abled and expert users as well, but we should also do our best to not needlessly exclude minorities from securely and effectively using Dolphin.

You call it a feature, some may call it a regression or a bug. I call it counterintuitive. Windows File Explorer works like this since 1995. If you feel like it's an improvement, by all means, offer it for NEW users who don't have the muscle memory of navigating directories for the last 30 years, but include an option/checkmark so people can still manually select the old (legacy) behaviour even if it isn't the default one. For example:

[x] highlight and select parent directory when going back/up

This is especially annoying when using the keyboard to navigate. Going up from a directory should not mean rebooting your computer and starting from scratch. There are directory trees with thousands of branches and that makes it unusable in any view, including tree.

Nautilus and our friends from Gnome, have adopted the following behaviour for going back in folders:

A small message saying "$directory_name" is selected (containing x items)

Deleting files by accident is a permission problem, but foremost a PEBCAK and not something a file manager should be solving. Just my 2 cents.

You're gonna end up writing code at some point anyway, so why don't you just add options with the different behaviors everyone wants? One for the old way, one for the new way, one for underlining the exited directory and so on. That way everyone's happy, no one's excluded and it will be up to the user to decide what's best for them. That way you'll remain true to the linux spirit - freedom. Otherwise you'll be just like Microsh1t, enforcing their view on the users.
Besides, isn't that also the spirit of KDE - adding tons and tons of options? So it's obvious and simple - add options in settings for the different behaviors and problem solved.

I think adding options that control this behavior is the most balanced solution, because both @mozo and @Felix Ernst are right from different points of view. By default it should be as Felix Ernst says, and as an advanced option it should be as described by @mozo

One vote for old behavior. Please do full select, with option for underline instead. This way it will be more consistent with previous version of Dolphin and classical OS. More over file browser is very important application in DE, more options will always be appreciated.

(In reply to Felix Ernst from comment #9)
> Dolphin should indeed be usable both for children as well as for
> cognitively, motorically, or visually impaired users, if possible. 

I agree, so please just add an option in the Accessibillity settings in order to cover that.
But please do not change something so trivial that is a standard in the file managers and can affect the workflow of majority of the users.
Also it seems that when navigating with keyboard there is no such issue, only mouse navigation is affected - where is the logic here?
Please consither reverting this change - it is rather irritating for me and I can see even more obstructing for others.
Thank you.

(In reply to Zeroadhesion from comment #15)
> Also it seems that when navigating with keyboard there is no such issue,
> only mouse navigation is affected - where is the logic here?

It would indeed be safer if no file was selected while navigating using the keyboard. However it would considerably slow down any keyboard-only file management if every action (aside from activating) would first require an explicit selection. This is different from a mouse-only workflow where navigating and selecting are always two separate and explicit actions (except for the two cases in which we used to implicitly select files which I have removed through the behaviour change this bug report is about).

While using a keyboard to navigate the singular selection of the current item is inherently safer because there is always at most one file selected which is also in view. The user cannot forget about it and keep a selection scrolled outside the view. Therefore one cannot encounter the scenario in which a user 1. emerges from a folder, 2. has that folder auto-selected, 3. scrolls down in the view using the mouse scroll wheel, 4. Clicks on a files "selection marker" to select it, 5. Deletes the newly selected file but also deletes the auto-selected folder (which is no longer in view) by accident.

>Please consither reverting this change - it is rather irritating for me
>and I can see even more obstructing for others.
>Thank you.

The lack of feedback when clicking a file or emerging from a folder is indeed not ideal.

We are discussing how to make it more obvious when a file is being activated or which folder one emerges from without always selecting them. Other application styles like "Fusion" or "MS Windows 9x" have a more visible styling for the current item. A short animation is also being considered.

This bug report remains open, which means the developer is considering that the issue may be valid and the behavior could be changed back, or modified in some way.

The best way to get the developer to change their mind and keep the current behavior as is is to act rude and entitled, or use charged language in the discussion ("Here's not a kindergarten", "you begin to wondering why someone should ruin your favorite file manager", "this plague is widespread"). I understand that this change has caused frustration, but please keep the discussion civil and technical. Failure to follow this advice will result in your comments being hidden or your bugzilla account being suspended.

Thanks for understanding.

I've confirmed the changed behavior in Dolphin 24.08.1
Previously, using Up or Back, the previous folder was highlighted and underlined
Now, it's only underlined which is much less visible

Mozo's Bugzilla account has been disabled for persistent rude and aggressive behavior even in the face of polite requests to desist.

Please keep it professional in Bugzilla tickets, folks — even if you find the issue extremely frustrating. Patience is a skill you learn by exercising it. I'm naturally impatient AF, so if I can learn it, anyone can!