Slightly strange behaviour in Dolphin

[amilias]

I was about to agree with @Slater91, but as usual things are not as straight forward

• If you enter a folder using the Enter-Key and then use “Go back”, the previous selection will be restored, meaning the folder you entered will be shown selected (and affect the “Create New Folder” Shortcut)
• If you select a folder and navigate around just by using “Go back” or “Go forward” the selection will also be restored on each view
• Now, if you navigate into the folder by using the Enter-Key but use “Go up”: the folder will not be selected anymore
• But, even more curious: if you decide to instead enter a folder by double clicking on it, no matter if you use “Go up” or “Go back”: the selection will always be gone

There’s probably a difference in navigating through the history (similar to how a browser might remember a web page state on using forward or back) compared to other navigation, which feels right, but for some reason double clicking “unselects”, which is a bit weird.

By the way, over in a different thread meven already wrote how he actually intended to go back to the previous “New folder” behavior after the poll results, but things seemed to have been mixed up by accident. So this thread can probably also slowly be laid to rest now.

[ben2talk]

@amilias

So this thread can probably also slowly be laid to rest now.

Thanks for this educational update on the navigation aspects… as you said, I was using Alt↑.. so I was wrongly assuming that the folder would never be selected.

[Slater91]

Thanks for trying that. Your findings only reinforce my point: there is now a hodgepodge of different behaviours, because things were changed to accommodate this new behaviour, but not uniformly. Which makes exactly zero sense! Why should the folder be selected based on whether you used your mouse or your keyboard to navigate? This will be another point to touch on later, in a different discussion/bug report, so that we go back some semblance of sanity.

It’s good to know that Méven will restore the old behaviour; as things stand, I haven’t updated to Dolphin 25.12 exactly to avoid the new one. I hope a fix will be merged soon so that I can update my system…

[redford]

@amilias

By the way, over in a different thread meven already wrote how he actually intended to go back to the previous “New folder” behavior after the poll results, but things seemed to have been mixed up by accident. So this thread can probably also slowly be laid to rest now.

That’s a great news, I was really annoyed by the change in behavior! Do you have any links/references to the change? I’m on 25.12.2 but Dolphin still creates directories inside the selected one.

[ggggeri91]

508196 – Create New Folder ignores selected folder and broken with mouse

514282 – Creating multiple folders with keyboard shortcut causes problems

515583 – Ctrl+Shift+N creates directory in a wrong place (subdir of the...

515929 – Allow configurability for creating folders/files within a selected...

A relevant pull request from Méven (not merged yet): dolphinmainwindow: disable selection after dir creation (!1137) · Merge requests · System / Dolphin · GitLab

[Krovikan]

Seems that they are agree to take this focus:

“The best implementation, will be to have two totally distinct actions, one for the shortcut and one for the context menu, so the shortcut is not visible there and we can have a distinct shortcut for each.”

https://invent.kde.org/system/dolphin/-/merge_requests/1137#note_1400212

Regards

[ben2talk]

@redford

I’m on 25.12.2 but Dolphin still creates directories inside the selected one.

I recently adjusted my CapsLock - so now to ‘latch’ the caps, I must press Shift_CapsLock (because I don’t use it often enough) and then CapsLock is an extra Escape.

This makes it more trivial to Escape with the left pinky, just as using the spacebar… so if you reach left to press Ctrl_Shift_N to create a new folder, you must escape.

I also find it annoying, but then some people expect that if a folder is highlighted a new folder should go inside.

Feels wrong… it’s also easy to enter folder1/folder2/folder3 for nesting… so now the biggest headache is if you’re IN a folder (maybe AudioDump) and want to create folders in the main view for mp3, aac, flac…

[ggggeri91]

I switched from Fedora to Kubuntu 25.10. Dolphin 25.08.3 is available in the backports PPA and works perfectly fine on my end.

Kubuntu 26.04 is coming soon, so we’ll see how things evolve. In the meantime, I’ve set up a development environment to build Dolphin from source with my own patch if necessary. I may be able to provide it via Launchpad should others be interested.

[meven]

There is a new MR to revert the commit introducing the behavior change:

Revert "!1026" (!1190) · Merge requests · System / Dolphin · GitLab

I expect it to land soon.

Then we can work on a proper solution.

[ben2talk]

@meven

Then we can work on a proper solution.

That’s really promising.

[outfrost]

Hi, wanted to chime in here since I just recently encountered the behaviour change on my distro, and initially thought Dolphin was just eating my folder create actions and creating nothing.

I haven’t had time to catch up on the entire discussion (it’s a book at this point, lol), but I hope this is a useful pov.

The Create New Folder default shortcut had been changed earlier (including in existing installations - something I’m against for accessibility reasons, but that’s another story) from F10 to Ctrl+Shift+N, which I presume at least in part to be intended as a convenience for users coming from other desktops and Windows. If KDE is following established UX patterns (and I’m pleased to say it mostly has been), then it would make sense to extend that to this issue.

But there’s another angle worth considering. On any desktop, including Windows, if we’re looking at a Select a Folder dialogue box, with a tree view of just folders, we do expect the New Folder button to create a new one under the selected one. IMO I believe this to be a distinction between details view and icons/compact views. If I’m looking at a tree, I know there are many places a new folder or file could be created, so it’s intuitive for me to first select the item under which the new one should appear. On the other hand, if I’m looking at a single-level list or grid, there is no such ambiguity. When creating a new file or folder in a single-level view, most users, especially inexperienced ones, expect to be able to see the new item immediately and interact with it. This is further reinforced by what happens in the Save File dialogue - if we create a new folder, the dialogue automatically navigates to inside that folder, because it is presumed that we want to save our file there. And, at least in icons view, the folder creation happens in CWD, regardless of selection.

I think the “Create new folder in …” text in the Create New Folder dialogue box is very much insufficient. As users, we presume this text to be exactly the same as where we expect to be creating a folder, so we ignore it, especially as we get quicker at using file managers and know that we just need to type a name for the folder. If an indication here were to successfully alert a user that they’re not creating a folder where they might expect to, it would have to be a significant visual change - for example, a 2-level tree representation, indicating that the new folder is not being created in CWD:

🖿 /path/to/selected/parent
|-- 🖿 [ New Folder          ]

I would be okay with either a preference setting or separate keybinds (changing a setting once is infinitely better than having the wrong behaviour every time), but I would recommend to consider what to do about details view vs icons/compact view. Do all users who expect “new folder under selected” expect that pretty much exclusively in details view (which is a tree view as mentioned earlier)? Should there be separate preferences depending on whether view is multi- or single-level? Should details view be a special case, where new items always spawn under selected? Should icons/compact views be a special case, where new items always spawn in CWD?

[meven]

@outfrost

I would be okay with either a preference setting or separate keybinds (changing a setting once is infinitely better than having the wrong behaviour every time),

That’s what I intend to implement at some point (as expressed already on invent), having two actions and two keybinds potentially, one for the shortcut and one for the selected folder from context menu case . Anyone welcome to do it, that’s not a big change.

@outfrost

but I would recommend to consider what to do about details view vs icons/compact view. Do all users who expect “new folder under selected” expect that pretty much exclusively in details view (which is a tree view as mentioned earlier)?

Users are different expectations and might not understand a behavior difference based on view.
But that’s a good point, the distinction list view/tree view.
Dolphin supporting both can’t really make a choice that would be consistent and easy to comprehend.

@outfrost

Should there be separate preferences depending on whether view is multi- or single-level? Should details view be a special case, where new items always spawn under selected? Should icons/compact views be a special case, where new items always spawn in CWD?

Those solutions seem simply too complicated, and will hurt some users.

Having in the dialogue explicitly the destination folder didn’t help much for instance.

[amilias]

I think I probably mentioned something along those lines earlier in this thread, but I agree that handling details view differently would be a good idea.
However: the create folder action should not just be limited to the “selected folder” but instead take the “current working dir” in relation to the current selection.

Take this example:

What would you expect the “create folder” action would do in this case?
I personally feel the most natural way would be to create a new folder in /tmp/test-details/folder 2/subfolder 1/"

Instead, even with this dolphin version that included the “create in subfolder” action, the new folder will currently be created in “/tmp/test-details/”. Only when explicitly selecting “subfolder 1” will the folder be created inside. This is a use case that won’t be solved by just offering two actions.

[skyfishgoo]

@outfrost

I would recommend to consider what to do about details view vs icons/compact view.

i strongly support this approach.

while not as “neat” codewise, it makes for a better UX and keeps within the tradition for power users who don’t use details view.

[skyfishgoo]

if you will notice the context menu in your use case does not offer the Create New... option because you have a file selected, rather than a folder… it is only when you select the folder that it is offered.

this same behavior should be linked to the Ctrl+Shift+N shortcut.

it should create the folder inside the selected folder, otherwise create it inside the CWD.

the problem is when you apply this to compact/icon view you end up creating a folder you can’t see, so that is why i advocate for treating them differently.

in compact/icon views it should always be handled as tho you intend to create the new folder in the CWD regardless of what is selected.

[amilias]

@skyfishgoo

if you will notice the context menu in your use case does not offer the Create New... option because you have a file selected, rather than a folder… it is only when you select the folder that it is offered.

this same behavior should be linked to the Ctrl+Shift+N shortcut.

Huh? So you want to remove the ability to create a folder while a file is selected? That’s pretty much the worst option imaginable. The context menu does not have to follow the exact same rules as global toolbar buttons and shortcuts, because it is by definition contextual, and dragging it into the discussion completely misses the point I tried to make.

[skyfishgoo]

@amilias

So you want to remove the ability to create a folder while a file is selected?

Shift+ctrl+N should:

create the folder in the CWD if no folder is selected OR if the view is either compact/icon view.

otherwise it should create the folder inside the selected folder, but only in that special case where both a folder is selected AND you are in details view.

whichever logic is easier to parse.