Bug 494125

Summary: Double-clicking a file *deselects* it after opening
Product: [Applications] dolphin Reporter: flan_suse <windows2linux>
Component: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: bonirar716, bugseforuns, felixernst, ilikefoss, kde, kfm-devel, kurobac, linux_rulez, linx.system.adm, mapatrapa, nate, nstefanovmo, p.r.worrall, pallaswept, postix, rodrigo.pedra, sannythebest95, serdarthtux, smowtenshi, spinatistgesund, tbertels, ttttolki, vse.stopchanskyi
Priority: NOR Keywords: regression
Version First Reported In: 24.12.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
URL: https://discuss.kde.org/t/dolphin-no-longer-highlights-last-visited-folder-after-navigating-back/30556
See Also: https://bugs.kde.org/show_bug.cgi?id=424723
https://bugs.kde.org/show_bug.cgi?id=492404
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description flan_suse 2024-10-04 16:10:53 UTC
SUMMARY
Double-clicking (to open a file) *DESELECTS* the file in question. This is a regression from earlier versions of Dolphin/Plasma.

This makes it difficult to know which file you were currently working with in Dolphin's window. You have to tap LEFT ARROW or RIGHT ARROW to select an adjacent file, which will once again "select" an icon for you to resume your workflow.

What makes this even more strange is that while the file's icon is deselected, hitting the ENTER key will open up the file again. (It's as if you clicked "empty space", when in reality you did not.)


STEPS TO REPRODUCE
1. Go to a folder with many photos (or any files)
2. Double-click to view/open the file
3. Close the file
4. BUG: The file's icon had already been "deselected" and is no longer highlighted

If you notice, this happens *immediately* upon the second mouse click when you double-click.

HINT: It acts *AS IF* you clicked empty space when you didn't.


EXPECTED RESULT
It should not deselect the file's icon when you double-click it.


SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux 
KDE Plasma: 6.1.5
KDE Frameworks: 6.5.0
Qt: 6.7.2
Dolphin: 24.08.1
Kernel: 6.11.0-6-MANJARO (64-bit)
Graphics Platform: X11
Graphics Processor: Mesa IntelĀ® Xe Graphics


ADDITIONAL INFORMATION
This also happens on Arch Linux (latest updates as of October 4, 2024), under a Wayland session.
Comment 1 Paul Worrall 2024-10-05 06:20:33 UTC
Can reproduce so setting status CONFIRMED

Does not occur if system is set to open items on single click

Operating System: Arch Linux 
KDE Plasma Version: 6.1.90
KDE Frameworks Version: 6.6.0
Qt Version: 6.8.0
Graphics Platform: Wayland
Comment 2 flan_suse 2024-10-05 16:10:21 UTC
(In reply to Paul Worrall from comment #1)
> Does not occur if system is set to open items on single click

Indeed.

It does not occur with "single-click to open" or if you use the ENTER key to open a file.

It only occurs (as a new bug) if you are using "double-click to open".

This might not be Dolphin-specific (maybe it's from a Plasma/Qt update), but it's the most obvious application to demonstrate this bug.
Comment 3 flan_suse 2024-10-20 03:29:40 UTC
This really hinders workflow, and it's very obvious.

Anyone who uses Dolphin will notice, including the devs.

Imagine going through a folder with images or videos, maybe to inspect them or decide how to organize them. You keep losing your location in the folder, since it acts like you just clicked "empty space".

It's to the point I want to revert back to an earlier version of Plasma before this bug existed. (Plasma 5?)
Comment 4 Felix Ernst 2024-10-29 13:54:47 UTC
There are plans to make the state when a file is "current" but not "selected" more visible. Currently there is only an underline under the name, which is not visible enough, so I understand your problem of "it [being] difficult to know which file you were currently working with in Dolphin's window."

Here is the current state of that issue: https://invent.kde.org/system/dolphin/-/issues/53
Comment 5 flan_suse 2024-10-30 00:05:32 UTC
(In reply to Felix Ernst from comment #4)
> There are plans to make the state when a file is "current" but not
> "selected" more visible. Currently there is only an underline under the
> name, which is not visible enough,

That's not the issue, though. This is a new bug (after some recent updates).

Previously, it doesn't matter how you opened a file, it would remain "selected.

Now, if you double-click to open a file, it (for some reason) reverts to a "hover" state, rather than the being "selected".

Try it:
Single-click to open? Works as expected. File remains "selected".
Enter key to open? Works as expected. File remains "selected".
Double-click to open? New bug! File is in a "hover" state.

Before some recent updates:
Double-click to open? Works as expected. File remains "selected".

Which update caused this new bug? I'm not sure. But it must be fairly recent. (I recall a new update where "Dolphin is now set to double-click to open by default". But that could be a red herring.)
Comment 6 Felix Ernst 2024-10-31 14:34:15 UTC
(In reply to flan_suse from comment #5)
> (In reply to Felix Ernst from comment #4)
> > There are plans to make the state when a file is "current" but not
> > "selected" more visible. Currently there is only an underline under the
> > name, which is not visible enough,
> 
> That's not the issue, though. This is a new bug (after some recent updates).

No, I did understand the behaviour change you are reporting. That change was intentional because we currently do not have any feedback e.g. when users are moving files to the trash which means they might delete files accidentally by pressing the Delete key. I made accidental deletion of files less likely by not implicitly selecting files during frequent actions like opening files. Similarly, it seems easier if only actual selection of files leads to selected files and not any type of interaction with a file.

My last comment was to make you aware of plans which should at least alleviate the issue you mentioned in the second paragraph of your initial report about not being able to identify the file one has last interacted with.
Comment 7 flan_suse 2024-11-01 01:31:16 UTC
(In reply to Felix Ernst from comment #6)
> I made accidental deletion of files
> less likely by not implicitly selecting files during frequent actions like
> opening files. 

Then why does *single-clicking* to open still keep the file selected?

Why does *pressing the enter key* to open still keep the file selected?

Why does this "safety feature" *only* affect double-click to open?
Comment 8 Felix Ernst 2024-11-01 17:08:25 UTC
(In reply to flan_suse from comment #7)
> Then why does *single-clicking* to open still keep the file selected?

Neither single-clicking a file in single-click mode nor double-clicking a file in double-click mode currently selects a file.

> Why does *pressing the enter key* to open still keep the file selected?

Because in a purely keyboard workflow moving around constantly selects the current item. You won't be able to scroll a selected item out of view simply by using the arrow keys. This is different to how the selection is simply kept when a user scrolls with the mouse. In a keyboard workflow it is expected that a user always has one item selected.

> Why does this "safety feature" *only* affect double-click to open?

It does not. This is also about going up in the file system hiearchy and single-click mode.
Comment 9 Filip 2024-11-24 12:26:44 UTC
*** Bug 496624 has been marked as a duplicate of this bug. ***
Comment 10 Mozo 2024-11-24 12:40:47 UTC
[Content removed]
Comment 11 Mozo 2024-12-10 10:50:56 UTC
[Content removed]
Comment 12 flan_suse 2024-12-10 15:35:56 UTC
(In reply to Mozo from comment #11)
> Please, I beg you, revert this change until the more visible icons problem
> is fixed. Please. It's reall PITA to work with many files. It's an everyday
> torture. Be human for a while.

I think these decisions are inorganic. They don't come from the bottom up, but rather are ideas that the developers decide to implement arbitrarily. We just need to be thankful, I guess.

Fun story: I was managing a large folder with photos, doing copy, move, and delete operations, and I had to keep *FORCEFULLY* re-selecting the last image I was looking at, in order to properly move it to another respective folder. (I made a few mistakes along the way because of this silly "safety feature" from the devs.) The entire process was painful. Of course, this isn't a problem on other desktop environments, nor was it a problem with an earlier version of KDE.
Comment 13 Mozo 2024-12-10 15:56:09 UTC
[Content removed]
Comment 14 J.D 2024-12-11 14:40:59 UTC
I'm seriously considering switching to a different file manager because of this new so-called feature.

So far the best thing I found is pcmanfm-qt. Mainly because it also has a permanent filter toolbar, which is rare among file managers. But it has drawbacks. Search isn't to my liking. It does not remember settings for individual directories. Bookmark icons can't be changed individually for at-glance identification.
Comment 15 username 2024-12-17 04:15:26 UTC
I will donate $1000 if this "feature" is reverted and prevented from happening again in the future
Comment 16 Mozo 2024-12-17 09:23:08 UTC
[Content removed]
Comment 17 Mozo 2025-01-01 11:31:37 UTC
[Content removed]
Comment 18 Patrick Silva 2025-01-15 13:03:14 UTC
This intentional change is clearly a usability regression. Sometimes I open a folder containing dozens/hundreds/thousands of files that I want to open and possibly delete immediately after closing them by pressing delete or shift+delete. After the change in Dolphin, pressing the said shortcuts has no effect, and also it's harder to found the last opened file (highlighted with a underline) in a folder containing dozens/hundreds/thousands of files.
Comment 19 kaminata 2025-02-15 09:51:38 UTC
Can we at least receive some patch for this regresison? It's out of my mind how this landed in the master...
Comment 20 flan_suse 2025-02-22 16:49:30 UTC
This change in behavior also affects folder navigation, as noted by a user on Reddit:
https://www.reddit.com/r/kde/comments/1ividwi/dolphin_no_longer_highlights_last_visited_folder/

I use KDE, COSMIC (Pop!_OS), Windows 10, and other DE's / file managers in the past. Only KDE's Dolphin behaves this way. You *really* feel like you're playing a game with the UI, rather than just enjoying your PC naturally.

The disruption in workflow shadows other features that might have been implemented in Plasma 6.2 and 6.3.

The file browser, other than a web browser, is one of the most heavily used features of a desktop environment. My workflow has been a frustrating experience ever since this change was slipped into an update. Every day I am reminded I'm using KDE... but not in a positive sense. Users shouldn't have to consciously think about overcoming a usability oversight.
Comment 21 kaminata 2025-02-28 11:27:21 UTC
There's an ongoing discussion on discuss.kde.org:
https://discuss.kde.org/t/dolphin-no-longer-highlights-last-visited-folder-after-navigating-back/30556/13

This really needs to be fixed.
Comment 22 John 2025-03-04 21:58:06 UTC
This is a very annoying bug!
Especially when working with multiple files like opening family vacations photos and videos one by one to show to someone something or to search for something in them.
Having so many in a folder or looking at one of the longer videos, it's very easy to forget after closing them where you were in the list.
Comment 23 kaminata 2025-03-16 17:50:21 UTC
Until this bug get fixed, here's a patch for the Arch users:
https://pastebin.com/aYhDHJe9
When there's a major version, just edit it accordingly.

I had forgotten how nice it is to use a normal file manager! I can breathe again!
Comment 24 J.D 2025-03-18 10:07:26 UTC
(In reply to kaminata from comment #23)
> Until this bug get fixed, here's a patch for the Arch users:
> https://pastebin.com/aYhDHJe9
> When there's a major version, just edit it accordingly.
> 
> I had forgotten how nice it is to use a normal file manager! I can breathe
> again!
This should be added:
    git config user.email "asd@asd.com"
    git config user.name "asd asd"
after that line:
    cd "${pkgname%-git}"

or makepkg would fail.
Comment 25 kaminata 2025-03-18 11:01:41 UTC
(In reply to J.D from comment #24)
> (In reply to kaminata from comment #23)
> > Until this bug get fixed, here's a patch for the Arch users:
> > https://pastebin.com/aYhDHJe9
> > When there's a major version, just edit it accordingly.
> > 
> > I had forgotten how nice it is to use a normal file manager! I can breathe
> > again!
> This should be added:
>     git config user.email "asd@asd.com"
>     git config user.name "asd asd"
> after that line:
>     cd "${pkgname%-git}"
> 
> or makepkg would fail.

Or you just can instal it via:
git config --global user.email "asd@asd.com" && git config --global user.name "asd asd" && makepkg -si
Comment 26 Salvatore 2025-04-04 04:55:03 UTC
I have di same problem

Operating System: Arch Linux 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.3
Dolphin version: 24.12.3
Comment 27 kaminata 2025-04-22 12:16:26 UTC
Here's the newest PKGBUILD for Dolphin v.25:
https://pastebin.com/5w8z1hzQ
Just issue in terminal:
makepkg -si
Done, the bug is gone.
Comment 28 Patrick Silva 2025-04-22 12:33:51 UTC
I get this result:

$ makepkg -si
==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.
Comment 29 J.D 2025-04-22 12:37:09 UTC
(In reply to Patrick Silva from comment #28)
> I get this result:
> 
> $ makepkg -si
> ==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.

Don't download the file from pastebin. copy-paste the content into an editor.
Comment 30 Patrick Silva 2025-04-22 12:55:23 UTC
(In reply to J.D from comment #29)
> (In reply to Patrick Silva from comment #28)
> > I get this result:
> > 
> > $ makepkg -si
> > ==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.
> 
> Don't download the file from pastebin. copy-paste the content into an editor.

Now the bug is fixed on my Arch thanks to you. :)
Comment 31 Thomas Bertels 2025-05-16 12:22:27 UTC
It's kinda strange that Dolphin has removed a behaviour which used to make it work like the main file managers:
Gnome Nautilus: https://youtu.be/D_YqONWOT0M?t=93
MacOS Finder: https://youtu.be/TY_ViHj4gFU?t=75
Windows Explorer: https://youtu.be/sf4l4YGXGt0?t=850

All this just because a single user complained repeatedly about it in bug 424723 while talking about possible data loss.

I don't understand how someone can miss the parent folder being selected when going back up a level, since it's in the middle of the view.

The commit[1] also removed an other standard behaviour which is that a file gets selected when we open it by a double click.
Note that the user in question didn't complain about that behaviour.

About the subject of "data loss", here are two examples with the current behaviour:
- A user wants to clean up their files by first opening each of them to double-check and then removing them if needed. The file that the user just opened isn't selected so the user could then remove the wrong one.
- A user wants to clean up their folders by first opening each of them(...): same thing as above.

[1]https://invent.kde.org/system/dolphin/-/commit/122fee5625f0285ec4ebda79162c72390989eb2a
Comment 32 John Kizer 2025-05-29 19:07:15 UTC
*** Bug 503183 has been marked as a duplicate of this bug. ***
Comment 33 Jesus 2025-07-03 19:07:38 UTC
Any changes regarding this bug? We've had this strange behavior for almost a year now. I'm sure it was done with good intentions, but the reality is that when inspecting files one by one it's very annoying to lose where you were. The line below is not enough, and if the window loses focus this line becomes almost invisible. Please revert this behavior or make it optional.
Comment 34 Felix Ernst 2025-07-03 23:21:35 UTC
(In reply to Jesus from comment #33)
> Any changes regarding this bug? We've had this strange behavior for almost a
> year now. I'm sure it was done with good intentions, but the reality is that
> when inspecting files one by one it's very annoying to lose where you were.
> The line below is not enough, and if the window loses focus this line
> becomes almost invisible.

Actually yes, as I had mentioned in comment 4 (https://bugs.kde.org/show_bug.cgi?id=494125#c4), we have made the appearance of the last-interacted-with item a lot more visible in https://invent.kde.org/system/dolphin/-/commit/c1e71289082ec7416ac19c822393ea70f63d1b75. Instead of only showing an underline, there will be a focus rectangle around the item similar to how keyboard focus is communicated on buttons and on text fields.

With this, one of the main issues described in the original bug report message ("This makes it difficult to know which file you were currently working with in Dolphin's window.") is resolved.
Comment 35 flan_suse 2025-07-04 13:59:41 UTC
Why can't this "feature" just be reverted or at least give us an option to disable it completely?

Even if you make the highlight easier to see (which it should ALWAYS be), it still does not address the issue of breaking workflows that other desktops and OS'es follow.

If I'm working in a folder: I open a file, make a decision about it, then close it, and hit F2. Uh oh! It brings up the bulk selection! What if I hit Enter to forcefully select the file? Uh oh! It opens up the file again! So instead I have to aim and click with the mouse to intentionally select it (again) and now I can rename it with F2. I might as well right-click and select Rename from the context menu, since I have to do the extra steps anyways.

Before this "fix" was applied to KDE (which you can see is unpopular and there was no genuine user demand for it), the workflow was much more intuitive and followed the same paradigms as ALL OTHER DESKTOPS. I cannot stress this enough.

Now there's also another funny inconsistency with this "feature". If I middle-click to open a file with an alternative program, it behaves as expected! The file REMAINS SELECTED and I can press  F2 or DEL like normal.

This "feature" was not demanded by the users. It breaks workflow. It's not even consistent with the rationale of why it was implemented in the first place.

Can we just REVERT it or give us an option to disable this unwanted behavior? Please?

Is this a reputation thing? Is it hard to accept that this has only upset the users, and that reverting the "feature" would be an admission that it was a mistake from the start?
Comment 36 kaminata 2025-07-04 14:58:34 UTC
I also think it's a mistake from the start and it's unwanted by the users and it makes their lifes actually harder. Please revert this change or make it optional. I migrate many users to Linux (KDE) and they find this behaviour confusing and they are constantly asking me why. Just accept it's unpopular and it's an obstacle to attract new users.
Comment 37 kaminata 2025-07-13 11:05:55 UTC
PKGBUILD for the newest Dolphin bersion to fix the bug:
https://pastebin.com/Wbs1TNzg
Comment 38 flan_suse 2025-07-13 18:10:33 UTC
(In reply to kaminata from comment #37)
> PKGBUILD for the newest Dolphin bersion to fix the bug:
> https://pastebin.com/Wbs1TNzg

I can't thank you enough!!!

I can use my keyboard *WITH* my mouse again.

Now if we can just find the commit that broke folder previews over network SMB shares...
Comment 39 kaminata 2025-07-13 21:37:07 UTC
(In reply to flan_suse from comment #38)
> (In reply to kaminata from comment #37)
> > PKGBUILD for the newest Dolphin bersion to fix the bug:
> > https://pastebin.com/Wbs1TNzg
> 
> I can't thank you enough!!!
> 
> I can use my keyboard *WITH* my mouse again.
> 
> Now if we can just find the commit that broke folder previews over network
> SMB shares...

Welcome and yes it's a relief. I don't know why it's taking them so long to fix it but let's hope it'll be soon. I didn't hear for one person who wants this change, it's insane.
Comment 40 Wolfgang Weber 2025-07-15 20:10:20 UTC
Once upon a time, a guy named Linus Torvalds talked about "interface nazis"...

Kind regards
Wolfgang Weber

(Not a hater, just another victim.)
Comment 41 thomasre 2025-07-15 21:39:15 UTC
(In reply to kaminata from comment #39)
> (In reply to flan_suse from comment #38)
> > (In reply to kaminata from comment #37)
> > > PKGBUILD for the newest Dolphin bersion to fix the bug:
> > > https://pastebin.com/Wbs1TNzg
> > 
> > I can't thank you enough!!!
> > 
> > I can use my keyboard *WITH* my mouse again.
> > 
> > Now if we can just find the commit that broke folder previews over network
> > SMB shares...
> 
> Welcome and yes it's a relief. I don't know why it's taking them so long to
> fix it but let's hope it'll be soon. I didn't hear for one person who wants
> this change, it's insane.

True, its extremly irritating to work with in this state. I don't see any benefit from implementing it this way.
Comment 42 Felix Ernst 2025-07-16 15:52:43 UTC
(In reply to Wolfgang Weber from comment #40)
> Once upon a time, a guy named Linus Torvalds talked about "interface
> nazis"...
> 
> Kind regards
> Wolfgang Weber
> 
> (Not a hater, just another victim.)

Yup, the person calling others nazis is the victim. This kind of conduct will get you banned.

Kind regards
Comment 43 Wolfgang Weber 2025-07-21 20:48:24 UTC
(In reply to Felix Ernst from comment #42)
> (In reply to Wolfgang Weber from comment #40)
> > Once upon a time, a guy named Linus Torvalds talked about "interface
> > nazis"...
> > 
> > Kind regards
> > Wolfgang Weber
> > 
> > (Not a hater, just another victim.)
> 
> Yup, the person calling others nazis is the victim. This kind of conduct
> will get you banned.
> 
> Kind regards

Hello Felix Ernst,

I think I'm in need to clarify some things (sorry for my English - it's not my native language). The main point is:

I really didn't want to call _anyone_ here at KDE a "nazi" (definitely not!). I just tried to remind the readers of my post on a talk Linus Torvalds gave several years ago. And when Mr. Torvalds talked about "interface nazis" back then, he expressed his dissatisfaction with the GNOME project because he thought their leadership and/or developers did not give their users enough freedom over the desktop they chose.

And yes, I admit that I'm indeed feeling similar regarding the "double-clicking a file"-behaviour KDE has been enforcing on their users for a few months now:
As far as I can remember, KDE was always here to give users more freedom and more choice than other desktops. And regarding this very special bug (494125), I feel my assumption might not be true anymore (what makes me truly sad)...

Why I am still feeling to be some kind of "victim"  (what a word - I know) of Dolphin's git commit 122fee56:

Workflow before:

Open file (for me it's a single click, not a double click - see Dolphin's settings)
View its content & close file
press F2 to rename the file

Workflow after:

Open file (for me it's a single click, not a double click - see Dolphin's settings)
View its content & close file

press cursor up
press cursor down

press F2 to rename the file

I really didn't find a better way yet - If you don't do it, you have to do "multiple selections". (And then you have to press "ESC" - even another unnecessary keystroke.)

That means (at least) two additional keystrokes per file you want to rename.
Probably not a problem, when you are renaming 3 files per quarter. But when you have to rename dozens files per day, per day, per day... it really gets annoying.

Summary:

- Unfortunately, KDE doesn't do enough to prevent people from calling them "interface nazis" (in Linus Torvald's meaning!)...
- Bug 494125 really annoys (at least the) people (posting here)
- If I should have insulted anybody in this or my previous posting, I truly apologize!

Kind regards
Wolfgang Weber

(The words of a seeker, not a hater.)
Comment 44 flan_suse 2025-07-21 22:33:03 UTC
>I really didn't find a better way yet

The best way is to build and install Dolphin that reverts these "enhancements".

See Comment #37 by kaminata

https://bugs.kde.org/show_bug.cgi?id=494125#c37

>I feel my assumption might not be true anymore (what makes me truly sad)...

I am saddened too. There are other "improvements" which have made me consider moving to another desktop after being a longtime user of KDE.

For now, using the PKGBUILD provided by kaminata is why I have not left KDE.
Comment 45 kaminata 2025-07-22 09:55:35 UTC
Yes, that's how intrusive this unwanted change is, yet nobody cares. It's out of my mind, really.
Comment 46 Thomas Bertels 2025-07-23 10:08:51 UTC
Please redirect the discussions to the topic referred above: https://discuss.kde.org/t/dolphin-no-longer-highlights-last-visited-folder-after-navigating-back/30556
The discussion here should be about the way to fix this, not about your feelings.
Comment 47 kaminata 2025-07-23 10:57:36 UTC
How to fix it? Just revert the change, I don't see a single person that likes it. And KDE is for users, right?
Comment 48 username 2025-08-19 23:17:09 UTC
Ok, a new version is out. It includes https://invent.kde.org/system/dolphin/-/merge_requests/946. Now it is easier to see which file is focused.

However, the root of the problem is still not fixed. If you open a file, then close it and press F2 - instead of the rename field, "Selection Mode" will appear. You still have to select the file again by clicking on it or using the arrow keys.
Comment 49 flan_suse 2025-08-20 18:38:30 UTC
(In reply to username from comment #48)
> However, the root of the problem is still not fixed.  

Correct. :(

It still breaks from established behaviors in all other desktops and OS'es.

I don't understand why it's so important to keep this "fix", especially when the "data safety" protections is not consistent across KDE/Plasma. This is the devs choosing what they think is best for the users. Hopefully they'll make it an option to let us choose.
Comment 50 kaminata 2025-08-20 21:39:30 UTC
(In reply to flan_suse from comment #49)
> (In reply to username from comment #48)
> > However, the root of the problem is still not fixed.  
> 
> Correct. :(
> 
> It still breaks from established behaviors in all other desktops and OS'es.
> 
> I don't understand why it's so important to keep this "fix", especially when
> the "data safety" protections is not consistent across KDE/Plasma. This is
> the devs choosing what they think is best for the users. Hopefully they'll
> make it an option to let us choose.

We escaped Microsoft and land on KDE. Soon it'll be the same. Sad.
Comment 51 Damglador 2025-08-24 22:22:52 UTC
Suggestion: can it be an option in settings? So people who depend on it can just turn it on. Though, considering (according to comments here) that it's a standard behavior everywhere else, maybe it's better to keep it on by default. This way, everyone is happy.
Comment 52 kaminata 2025-09-06 21:47:57 UTC
Here's the patch for the latest Dolphin version until this bug get fixed:
https://pastebin.com/5YiQbXr4
The annoying focus indicator is removed as well. You can use Dolphin like a normal file manager now.