i don’t think solving the “what ends up selected” question after an action like Create New Folder… to be automation.
it’s just a GUI default behavior question… and the default behavior should be consistent for a good UX.
if i just created a folder, my expectation is that it should be selected without any further escape or enter button presses on my part.
if i just deleted a folder, i would expect the parent folder to be selected, not the next folder in the list.
and so on.
The two possiblities that make sense:
Click ‘create folder’ always creates the new folder in the parent regardless of the updated selection.
Click ‘create folder’ creates the new folder, which is selected, then the next time it creates a folder inside - but a third click would create a new folder inside the inner ‘New Folder’ so that you’d end up with them all nested.
I’d call this ‘The Principle of Least Surprise’… and this is the principle that is being violated by alternating behaviour.
When you create a new folder in ‘HOME’, you are still in ‘HOME’, so ‘Create New Folder’ should still create it in ‘HOME’.
The act of creation does not imply that you want to navigate or enter the new folder…
What is the USER is intending to do when they click the ‘Create New Folder’ button two or three times?
I’d say nesting would be a minority case and the USER would expect to control navigation.
That’s why I was suggesting that it’s an ‘automation’.
ah, i see the difference in what you describe is changing the PWD by “automating” an Enter key press… i don’t think anyone is suggesting that.
Selected simply means the selection highlight in dolphin, not actually changing PWD to the new folder.
in my plasma 5 world: F10 creates a new folder in PWD as per your item 1…. the only way for me to create nested folders is to use the context menu (which requires me to Select something)
in the flatpak version of dolphin with the change applied, the Ctrl+Shift+N option creates a new folder at a location that depends upon what is selected, just like using the context menu.
the change brings both use cases of the Create New Folder dialog in line with each other… which is a desirable thing.
the issue you bring up stems what ends up Selected in the GUI after a new folder is created.
there are two use cases for the Create New Folder dialog
CASE 1: Create a new folder in PWD
CASE 2: Create a nested folder in Selected
the missing link in CASE 2 is the last step where after folder creation the GUI expands the folder tree to reveal the new folder and shows the new folder as Selected (and only the new folder).
CASE 1 already does this step without any difficulty because no expansion of the folder tree is needed to show the new folder and mark it as Selected, but when creating a nested folder more GUI work needs to be done to show it.
Hi Everyone,
I opened a new bug with a nice test scenario, please take a look: https://bugs.kde.org/show_bug.cgi?id=510757
I will copy-paste it here, because it represents all the pain regarding the new change:
1. Create a new folder named "test"
2. Navigate into "test"
3. Press Ctrl+Shift+N, enter "1" as folder name, press ENTER
4. Press Ctrl+Shift+N, enter "2" as folder name, press ENTER
5. Press Ctrl+Shift+N, enter "3" as folder name, press ENTER
6. Press Ctrl+Shift+N, enter "4" as folder name, press ENTER
7. Press Ctrl+Shift+N, enter "5" as folder name, press ENTER
8. Press Ctrl+Shift+N, enter "6" as folder name, press ENTER
9. At this point, the "test" folder will contain "1", "3", "5" folders. I am not joking.
Actual:
```$ tree test
test
├── 1
│ └── 2
├── 3
│ └── 4
└── 5
└── 6
Expected:
$ tree test
test
├── 1
├── 2
├── 3
├── 4
├── 5
└── 6
This bug has been introduced in a commit regarding this other issue: https://bugs.kde.org/show_bug.cgi?id=508196
In my opinion, the original behavior is a sane choice. The new folder always should be created within the current WORKING DIRECTORY. Every other file explorer follows this principle, and you may understand from where my frustration is coming from.
Creating new folders with the CTRL+SHIFT+N keyboard shortcut is no longer straight-forward. As a work-around, I have to press the ESC key after - each - damn - new - folder. Do you see the problem gentlemen?
“All the other file managers act like X” just seems like a lack of appreciation of how Dolphin is so much more powerful than all the other file managers. Other file managers work like that because they don’t have a choice.
And now we - as Dolphin users - don’t have a choice either, until this function could be disabled
(And I’m pretty sure any other filemanager could behave like this, simply nobody want them to)
yes, this has been discussed at length here.
the behavior is entirely expected given how dolphin sets the focus after the creation a new folder.
the parent folder has focus then a child folder is created (this was the only option prior to the recent change).
now if a single folder has focus then it will create a child folder within that folder (nested)… this behavior is new.
if however you have just created such a folder then the focus is no longer clear … it is neither the parent folder, nor it is the child folder you just created, so dolphin defaults back to the parent folder again which gives you folder 3
the change was only recently introduced in order to provide the ability to make a child folder within a selected folder, but there were unforeseen side effects to that change that have yet to be dealt with.
in the mean time you will just have to pay attention to what is selected each time you press Ctrl+shift+N
Pretty simple: get rid of this whole nested thing.
Boooo
It’s awesome.
It just needs a little more love from the devs so it’s all polished mate it’ll be fine chill out on the axe-wielding there 
I forgot to mention that I am using the default view in Dolphin: Icons.
I noticed in the discussions that this change is probably induced by the users of the Details view which displays a file system tree. What do you think guys, is this observation correct?
Since the default and most used view in Dolphin is Icons, it is a real problem when the good and tested workflow changes in such a significant way in order to satisfy a feature request regarding another - completely different - view: Details.
May I suggest to add a check on the current view, and apply the new behavior only for Details view? Any comments on that?
By the way, this new change is already in the latest Kubuntu release: 25.10 (and Fedora, and others …) and I can tell you most of the users I met are disturbed by this change as it really interrupts the workflow when working with folders. They think it is just another bug and will be fixed.
Actually I hadn’t thought to try it in Compact, as I don’t use that often - but with the Details view I think it’s exactly the same, new folder then nested folder, then another new folder and another nested folder.
Still a bit weird.
“All the other file managers act like X” just seems like a lack of appreciation of how Dolphin is so much more powerful than all the other file managers. Other file managers work like that because they don’t have a choice.
Maybe I phrased it wrong, but I just tried to point out that if something is working in a certain way everywhere else in the world and nobody complains, it might not be the best idea to change that default behavior. At least give us an option to toggle this, why not?
I mean… here I am complaining about a basic thing: creating new folders in the flagship file explorer of KDE Plasma Desktop. I have never thought about doing this before I can assure you. I also do not understand why such a basic feature must be overengineered as f*ck.
1. Create a new folder named "test"
2. Navigate into "test"
3. Press Ctrl+Shift+N, enter "1" as folder name, press ENTER
4. Press Ctrl+Shift+N, enter "2" as folder name, press ENTER
5. Press Ctrl+Shift+N, enter "3" as folder name, press ENTER
6. Press Ctrl+Shift+N, enter "4" as folder name, press ENTER
7. Press Ctrl+Shift+N, enter "5" as folder name, press ENTER
8. Press Ctrl+Shift+N, enter "6" as folder name, press ENTER
9. At this point, the "test" folder will contain "1", "3", "6" folders. I am not joking.
Actual:
```$ tree test
test
├── 1
│ └── 2
├── 3
│ └── 4
└── 5
└── 6
Expected:
$ tree test
test
├── 1
├── 2
├── 3
├── 4
├── 5
└── 6
This sums up the situation nicely. It is clear that the new change introduced unwanted side-effects. I am complaining about these side-effects, I have no problem introducing new optional features to give us the users the choice.
Especially when we think that the old behavior was fine for decades till version 25.08.0, but in 25.08.2 it had to be changed because… reasons…? And it was so important that it was back-ported to 25.08.1 as well and landed already in major Linux distros.
I mean how often do you REALLY create folders in batch ? Is dolphin the best tool(legitimate?) to accomplish this?
Creating new folders one after the other is supposed to be a very basic task in a file manager, is it not? Are you telling me that a user should use the terminal or another file manager to perform such basic task?
Worked just fine till 25.08.0. Please do not try to ignore the past few decades of Dolphin 
dolphin simply needs decide which directory to select after creating a new folder.
prior to the change
each time you hit Ctrl+Shift+N a new folder was created in PWD regardless of focus or selection
* however after the folder is created, the focus and selection are moved automatically to the newly created subfolder, presumably so the user can do more work with it, but that now seems opinionated in hind sight.
after the change
for each Ctrl+Shift+N a new folder is created within the whichever folder is selected and has focus.
with nothing selected, then PWD has focus and a new folder is created in the PWD and it is selected and given focus automatically just like prior to the change
however, with a folder selected, then a new folder is created as a subfolder (much like using the context menu on a selected folder prior to the change)
now, at this point nothing is selected and the focus is blurred, spread between the newly created subfolder and the parent folder (note that the context menu option is unavailable in this condition because of the focus ambiguity).
this blurry state of focus is what needs to be resolved for this feature to work properly.
either 1) or 2):
the only viable way to handle this is condition is to automatically switch the PWD to the newly created folder which disrupts the folder creation workflow if you intend to be working in the original PWD.
conclusion
there is no way to make a viable Ctrl+Shift+N feature work beyond one level deeper than the selected folder and that option 1) is the only viable way to resolve this ambiguity.
this is also where the folder name including the special / character comes into it’s own, as nested folders can easily be created in one go without having to navigate to each one.
so if the intent is to crate a nested set of folders under folder 1, then one would use Ctrl+Shift+N and enter 1/2/3/4/5/6
if the intent is to create a bunch of numbered subfolders in PWD then one would just evoke Ctrl+Shift+N for each one separately.
I like the option 1. More logical.
Regards
Basically, pressing ENTER to get nesting is also extremely logical and I don’t see the benefit of the change…
At least not yet ('cos everything I know today might be proved wrong tomorrow).
Agreed.
No.
Dolphine needs to stop caring about selections when creating folders. Folders should be always created in the working directory. Period
Like it did before, like every other filemanager does. Like everyone expects.
Then it’s going to be absolutely irrelevant what is selected after creating a new folder (btw that new folder should be selected)
I think this summarizes the current state of things really well. Regardless of whether I’m operating a terminal or file manager, I expect actions to happen in my current working directory. Unless I pass commands that explicitly direct my terminal or file manager to operate in another directory, it should not interact with it.
I think the hardest pill for me to swallow is that this behavior is intentional. I understand the desire to keep unnecessary options out of the configuration panel, but as someone who uses shortcuts all the time: This is an annoying time-waster and leads to unexpected behavior.
I’ll be using mkdir for now.