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!

As a devil's advocate, I took up this argument with the banned OP in KDE Discuss. The initial (inaccurate) statements seem to have been accurately distilled into two main issues which can, indeed, affect workflow.

The first item being a minor annoyance, the second item more of an issue:

1. When returning to a parent folder, it is marked too subtly.
2. When returning to a parent folder, it is marked active, but not selected.

I frequently hit F3 to go dual pane before entering a folder; for this scenario, I'll say I have downloaded a bunch of mp3 files to /music/mp3.

Let's enter mp3, convert them all to opus, then return to the parent - then possibly rename it to 'opus' (now not possible, hitting F2 now enters 'selection' mode despite the 'current file' being already highlighted).

Shift+F6 also will enter selection mode rather than move that folder to the other pane... it will need to be re-selected and I'm not sure how to do that other than use the arrow key.

Ben, I appreciate your feedback and tests, which show how this problem affects more than one thing about the user experience.

Unfortunately, I think that trying to go point by point misses the bigger picture: Deselecting an opened item or visited folder should never have been made into the default, and I would argue it should never have made it into KDE *at all*. The reasons are plenty. You've explained some yourself. So have I in another bug report. So has another user on Reddit.

The best solution is to revert this change that breaks workflow and muscle memory. I have yet to see a large userbase request that Dolphin diverge from all other file browsers in this regard. (To the devs: Make an "option" in Dolphin f it's really that important. You can call it "Deselect opened files and folders".)

No other OS'es or DE's do this: Not Windows, COSMIC, MATE, Xfce, GNOME, or even earlier versions of KDE.

If the rationale is "We want to prevent users from accidentally deleting their files", then it still doesn't make sense in the context of KDE:

1. This is babysitting users, without a means to disable the "safety feature"

2. It's *inconsistent* with KDE: They recently added a new context menu called "Extract here and delete", which cannot be removed from the menu. I have accidentally trashed my archives multiple times because of this menu item. I cannot even disable it. This is sending mixed messages: "We want to protect our users from accidentally deleting things, but also we want to make it really easy to accidentally delete things".

(In reply to Ben Guy-Williams from comment #27)
> 1. When returning to a parent folder, it is marked too subtly.

Yes, this is something we want to change regardless of this bug report here. This is tracked in https://invent.kde.org/system/dolphin/-/issues/53. Just needs someone to put the work in.

> 2. When returning to a parent folder, it is marked active, but not selected.
> 
> I frequently hit F3 to go dual pane before entering a folder; for this
> scenario, I'll say I have downloaded a bunch of mp3 files to /music/mp3.
> 
> Let's enter mp3, convert them all to opus, then return to the parent - then
> possibly rename it to 'opus' (now not possible, hitting F2 now enters
> 'selection' mode despite the 'current file' being already highlighted).

Yes, with the current state of Dolphin it is necessary to first select the folder. Nothing is selected when returning to the parent folder, similarly to how nothing is selected when a folder is opened by activating it in the "Places" panel, when opening a folder by activating it in the main view, when opening a new tab, or when opening an URL from outside of Dolphin.

> Shift+F6 also will enter selection mode rather than move that folder to the
> other pane... it will need to be re-selected and I'm not sure how to do that
> other than use the arrow key.

Ctrl+Space will select the current item. Simply "Space" by itself will also do this, but only if you don't have bound "Space" to be the keyboard shortcut of some other feature (which it currently is by default). In selection mode with the latest Dolphin release, pressing "Enter" will also select the current item.

(In reply to flan_suse from comment #28)
> Ben, I appreciate your feedback and tests, which show how this problem
> affects more than one thing about the user experience.
> 
> Unfortunately, I think that trying to go point by point misses the bigger
> picture: Deselecting an opened item or visited folder should never have been
> made into the default […]

The bigger picture really also must take into account that it is very easy to move items to the trash by accident when items are implicitly selected. 

> 1. This is babysitting users, without a means to disable the "safety feature"

It is not just babysitting. One does not need to be dumb or clumsy for this to happen (previous to the change you want to see reverted):

A user just needs to click the semi-transparent selection rectangle on top of a file icon instead of clicking the file itself in double-click mode, and then the file is added to the selection instead of becoming solely selected by itself. Press "Delete" or a muscle memory "Shift+Delete" into "Enter" then, and instead of only permanently deleting the file the user just clicked on, any previously selected files will also be permanently deleted. All of that only because the user clicked a selection rectangle by accident whose existence they might not even be aware of because it only appears on hover!

> muscle memory

> No other OS'es or DE's do this: Not Windows, COSMIC, MATE, Xfce, GNOME, or
> even earlier versions of KDE.

I understand the frustration, but we really need to find a solution that prevents such accidental data loss to happen. Sorry about the break of muscle memory, but other file managers might for example not have such selection rectangles that allow accidentally adding files to a selection. Whatever they do differently does not change the fact that we would have even less safeguards against data loss if we automatically select files on the users behalf. A user first needing to select a file before acting on it is one way to make sure of this (Keyboard-only users are exempt from this). There are various we could change Dolphin which might similarly prevent the data loss scenario described above. If we find a good way, we might be able to revert that change.

What I don't want to see is a change that re-introduces that potential for data loss, just because we value muscle memory in mixed workflows of mouse navigating and then activating keyboard shortcuts higher than data loss. Even though it really only takes one extra click to work around this change. I hope you understand.

> 2. It's *inconsistent* with KDE: They recently added a new context menu
> called "Extract here and delete", which cannot be removed from the menu. I
> have accidentally trashed my archives multiple times because of this menu
> item. I cannot even disable it. This is sending mixed messages: "We want to
> protect our users from accidentally deleting things, but also we want to
> make it really easy to accidentally delete things".

So, I was not aware of such a change, and it actually is *not* a Dolphin change. That "Extract here and delete" action is provided by Ark, not Dolphin.

That being said, the common logic is that there should be no accidental data loss. "Extract here and delete" is probably not meant to cause data loss, because the data from that archive is extracted. While the archive will be deleted, its contents should survive. If this is not the case, I would consider this a bug we should prioritise to fix.

>I understand the frustration, but we really need to find a solution that prevents such accidental data loss to happen. 

Make it an *option*. End of story.

I'm really becoming exhausted with this uphill pleading *after* a major workflow change is hardcoded into KDE / Dolphin.

>That being said, the common logic is that there should be no accidental data loss. "Extract here and delete" is probably not meant to cause data loss, because the data from that archive is extracted. While the archive will be deleted, its contents should survive. If this is not the case, I would consider this a bug we should prioritise to fix.

Common logic is you don't hardcode a context item to send archives to the trash if protecting against accidental data loss is really the priority.

When you're dealing with a lot of files in a folder, this operation (without asking for confirmation) sends the file straight to the trash, and sometimes I don't catch it. What if I then empty the trash? What if I only needed to review and work with some files temporarily, which I later intentionally delete? If I had missed/forgotten about the original archive that got trashed, then I am SOL. (Really baffles me why this menu item is displayed by default, and without a means to disable it. If anything, a user should have to *opt in* for this menu item to be shown, since it involves deletion.)

I know the devs don't find this constructive, but with what has been happening with KDE recently (especially without *options*), I'm seriously considering just fully migrating to COSMIC when it releases. I *don't* want to. I really don't. I've been using KDE for a very long time. I think it's the best Linux desktop environment, especially for its many options and customizations.

It's sobering to see what's happening to basic mouse and keyboard usage, and what feels like change for the sake of change.

>1. This is babysitting users, without a means to disable the "safety feature"

>2. It's *inconsistent* with KDE: They recently added a new context menu called "Extract here and delete", which cannot be removed from the menu. I have accidentally trashed my archives multiple times because of this menu item. I cannot even disable it. This is sending mixed messages: "We want to protect our users from accidentally deleting things, but also we want to make it really easy to accidentally delete things".


More inconsistency with implementation and messaging:

3. Select and delete multiple files in a folder. Now the next file in the display is arbitrarily *selected*, which is at risk of "accidental" deletion with the keyboard.


Since this change landed, it not only adds friction to using the file browser, but it's not even consistent with the principle of "minimize accidental deletions".

There's a reason no other OS'es or DE's do it this way. KDE doesn't need to diverge from well established designs.

If the devs really insist that KDE needs to implement this: Make it an *option*

We have to play these weird games to work around this new behavior, which is not even consistent. (I still cannot get over the fact that "Extract here and delete" is a hardcoded  context menu item for archive files, with no means to disable it. It comes off as disconnected to tell users "Well, you'll sill have a copy of the extracted files, right?")

(In reply to Felix Ernst from comment #29)
> Yes, this is something we want to change regardless of this bug report here. This is tracked in https://invent.kde.org/system/dolphin/-/>issues/53. Just needs someone to put the work in.

Which doesn't happen for a year yet you made the change and nobody can see the underlined items.

(In reply to Felix Ernst from comment #29)
>A user just needs to click the semi-transparent selection rectangle on top of a file icon instead of clicking the file itself in double-click mode, >and then the file is added to the selection instead of becoming solely selected by itself. Press "Delete" or a muscle memory "Shift+Delete" >into "Enter" then, and instead of only permanently deleting the file the user just clicked on, any previously selected files will also be >permanently deleted. All of that only because the user clicked a selection rectangle by accident whose existence they might not even be >aware of because it only appears on hover!

There's an option for selection rectangles in Windows as well, still there's no such measures like this.

(In reply to Felix Ernst from comment #29)
>I understand the frustration, but we really need to find a solution that prevents such accidental data loss to happen. Sorry about the break >of muscle memory, but other file managers might for example not have such selection rectangles that allow accidentally adding files to a >selection.

There's a reason no other file manager or OS do it this way. If it's so important to you, make it an option. and everyone will be happy.

(In reply to flan_suse from comment #31)
> More inconsistency with implementation and messaging:
> 3. Select and delete multiple files in a folder. Now the next file in the
> display is arbitrarily *selected*, which is at risk of "accidental" deletion
> with the keyboard.
> 
> 
> Since this change landed, it not only adds friction to using the file
> browser, but it's not even consistent with the principle of "minimize
> accidental deletions".

Yes, I also noticed that after this change has landed. Now, when you delete a file or multiple files, the adjacent file is explicitly selected, and you might accidentally delete it, which is quite dangerous.

Felix, please revert this change until it's more cleare if it's wanted or not. Thank you!

Hmm, interesting. Seems like changes that break muscle memory garner especially much hate when justified with protecting computer illiterate people and minorities. I was hoping we could discuss solutions here which make the people in this bug report happy while not regressing on the bug fix which lead to this bug report. However, my attempts at explaining the situation only lead to people thinking that talking down to me repeatedly would evoke a code change.

I have mentioned various fixes that could be implemented without regressing the original objective of preventing accidental deletions. Completely independent of anything happening on this bug report page, there are different additional solutions which we have discussed internally among Dolphin contributors. If any contributor is interested in working on them, please contact the usual development channels. I won't lay them out here because this page has become quite off-topic and fact-free, and I assume what I write here will be lost in the noise.

(In reply to kaminata from comment #35)
> I haven't seen a single person who is happy with this change, except for Felix.

The bug reporter who asked for the change is not me. Naturally, a bug report will gather all the people who are affected by the same bug. This can become an echo chamber in that regard.

(In reply to kaminata from comment #32)
> Which doesn't happen for a year

This bug report is 6 month old.

> Yes, I also noticed that after this change has landed. Now, when you delete
> a file or multiple files, the adjacent file is explicitly selected, and you
> might accidentally delete it, which is quite dangerous.

This is completely unrelated to the change you ask to be reverted and to this bug report.

(In reply to flan_suse from comment #30)
> Common logic is you don't hardcode a context item to send archives to the trash

You might want to report this to Ark developers instead of venting about it in an unrelated bug report of an unrelated project. The people responsible for that change are unlikely to ever read it here.

If you feel the need to further point out how illogical my reasoning was, and how I solely am forcing you all to suffer like the small-minded dictator that I appear to be to you, I welcome you to write additional comments below my comment here. No promises I will read them though, and it is especially easy for KDE developers to ignore comments which show signs of hostility. Good luck!

The current course seems unlikely to end in a positive resolution, as we'll become more upset and entrenched in our positions. I would recommend we all take a step back and brainstorm solutions constructively that address the original goal: "make it harder for normal users to accidentally lose data". Surely that's a goal we can all agree on.

Here's an idea:

Show a small in-window notification (if this were QML, I'd suggest a Kirigami.PassiveNotification()) every time something is moved to the trash, which includes an Undo button on it. This way it will be almost impossible to miss that something was trashed, even if it was accidental. That should be enough of a safety margin to allow reverting the original change.

This is just an idea, maybe a bad one, but an example of the kind of brainstorming that may offer a way out of the current logjam.

(In reply to Nate Graham from comment #37)
> This way it will be almost impossible
> to miss that something was trashed, even if it was accidental. That should
> be enough of a safety margin to allow reverting the original change.
> 
> This is just an idea, maybe a bad one, but an example of the kind of
> brainstorming that may offer a way out of the current logjam.

Thank you Nate for thinking out of the box and trying to balance between devs and users!
Even if this won't lead to anything, it's appreciated!

(In reply to Nate Graham from comment #37)
> The current course seems unlikely to end in a positive resolution, as we'll
> become more upset and entrenched in our positions. I would recommend we all
> take a step back and brainstorm solutions constructively that address the
> original goal: "make it harder for normal users to accidentally lose data".
> Surely that's a goal we can all agree on.
> 
> Here's an idea:
> 
> Show a small in-window notification (if this were QML, I'd suggest a
> Kirigami.PassiveNotification()) every time something is moved to the trash,
> which includes an Undo button on it. This way it will be almost impossible
> to miss that something was trashed, even if it was accidental. That should
> be enough of a safety margin to allow reverting the original change.
> 
> This is just an idea, maybe a bad one, but an example of the kind of
> brainstorming that may offer a way out of the current logjam.

Thanks!
I'll suggest to make it an option. It's even ok Felix' approach to be by default. This way everyone who's affected can turn it off.

The suggestion to make it an option has been shared multiple times, even on the other related bug reports.

Everyone wins.

This is not just about "hard to see the underline". This also involves workflow and QoL.

Regardless if another fix makes the "highlight" easier to see, it still breaks using keyboard shortcuts. As noted by another user: You cannot simple hit "F2" after returning to the previous folder or closing the file. You must first intentionally select the file (again) just to do this basic task.

When a file or folder is not *selected*, it breaks keyboard usage.

Multiple examples were shared. Here are but a couple more:

1) You work/view inside a subfolder. After you're done, you go back and hit F2 to rename it. Rinse and repeat with many subfolders.

2) You open images in a folder, assessing whether or not to keep them. After closing a file, you can immediately send it to the trash or rename it based on your criteria. Some files get skipped, others need to be renamed or trashed. Repeat many times over.


> You might want to report this to Ark developers instead of venting about it in an unrelated bug report of an unrelated project. 

I was bringing it up because, as a user of KDE, there is obvious inconsistency about "protecting users from themselves".

On the one hand it's really easy to accidentally trash files. With Dolphin, when you *delete* a single file or multiple files, it *selects* the next file in the folder. Now *this* file is at risk for "accidental deletion".

On the other hand, it's the opposite. With Dolphin, when you *open* a file or *navigate* backwards, it *deselects* the file or folder.

I mentioned Ark as yet another example of this inconsistency of the desktop experience.

As a user of KDE who uses it every day, this inconsistent behavior comes off as unpolished, like a beta software still trying to find its identity. This wasn't the case until recently.

We plead with you: Make it an *option*. Leave it as the default if you want, but make it an *option*.

I would also recommend that Dolphin's behavior remains *consistent*, depending on whether or not the "protection" is enabled. "If I do *this* thing, it's easy to accidentally trash a file/folder, but if I do this *other* thing, then the file/folder is not selected."

Hi,

I read in the thread that pressing "Space" reselects the "highlighted but not selected" file.

I've got Space mapped to something else.

I'm not sure what action to select from the shortcuts page to peform the "space key to reselect" function.

"Select" enters "Selection Mode"
"Select Files and Folders" enters "Selection Mode"

cheers.

Poor guy...
https://discuss.kde.org/t/dolphin-no-longer-highlights-last-visited-folder-after-navigating-back/30556/15

I know this page has become a bit of a mixed bag of comments and issues now, but the original issue as described by the original bug reporter has been resolved now.

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

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

https://invent.kde.org/system/dolphin/-/commit/c1e71289082ec7416ac19c822393ea70f63d1b75 has made the keyboard focus indicator way more obvious. It is no longer just an underline but a focus rectangle around the item. This change will land in Dolphin 25.08.

Thank you for your patience.