Hi, I'm afraid Dolphin 22.12.3 no longer receives updates or maintenance from KDE; active versions are 25.04.3 or newer. Please upgrade to an active version as soon as your distribution makes it available to you, or use other application distribution methods such as Flathub. Dolphin is a fast-moving project, and bugs in one version are often fixed in the next one.

 If you need support for Dolphin 22.12.3, please contact your distribution, who bears the responsibility of providing help for older releases that are no longer receiving updates from KDE.

If this issue is still reproducible in a supported version of Dolphin, feel free to re-open this bug report.

Thanks for understanding!

See: https://i.imgur.com/uBSmsBm.png

I selected Downloads and Ctrl+Shift+N and as you see it will New Folder will be created in /home/c2 not in /home/c2/Downloads

This is the flatpak version I installed with 

flatpak install flathub org.kde.dolphin
flatpak run org.kde.dolphin

There is another issue in this version. With the mouse when you right click a folder and then click Create new folder, then it  does not show any dialog at all to enter the name.  The context  menu apparently was only tested in the opened folder background or not at all. Imho when a context menu appears it should work. When it is not supposed to work, then the context menu should not appear either. 

In defense I call this functional regression. These were the early revolutionary UX advances of the graphical UI that nowadays seem taken for granted. These should be included in the UX tests, cherished like gold. Is Dolphin ready for voice commands like "Dolphin, create new folder in Home Downloads called KDE"? Until that works flawlessly you still depend on the old UX and its functionality need to be tested.

Git commit 24d859cf19e90fa22ed687b36a68231625c1bd80 by Méven Car, on behalf of lzwind lzwind.
Committed on 26/08/2025 at 09:24.
Pushed by meven into branch 'master'.

Make create folder use selected directory

This change makes `Ctrl+Shift+N` behavior consistent with right-click context menu:
- If a single directory is selected, create inside it
- Otherwise, create in current working directory

M  +20   -2    src/dolphinmainwindow.cpp

https://invent.kde.org/system/dolphin/-/commit/24d859cf19e90fa22ed687b36a68231625c1bd80

*** Bug 507490 has been marked as a duplicate of this bug. ***

*** Bug 508823 has been marked as a duplicate of this bug. ***

*** Bug 508537 has been marked as a duplicate of this bug. ***

*** Bug 508353 has been marked as a duplicate of this bug. ***

Running 7d224aab, the context menu issue is still present?

*** Bug 508898 has been marked as a duplicate of this bug. ***

Git commit 65bb95f50ed591c8e5c7b07b9ef6072dfcecf89e by Méven Car.
Committed on 01/09/2025 at 11:07.
Pushed by meven into branch 'release/25.08'.

Make create folder use selected directory !1026

This change makes `Ctrl+Shift+N` behavior consistent with right-click context menu:
- If a single directory is selected, create inside it
- Otherwise, create in current working directory


(cherry picked from commit 24d859cf19e90fa22ed687b36a68231625c1bd80)

900d5d8f Make F10 create folder respect selected directory
e5ebe618 Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: lzwind lzwind <liuzheng@uniontech.com>

M  +20   -2    src/dolphinmainwindow.cpp

https://invent.kde.org/system/dolphin/-/commit/65bb95f50ed591c8e5c7b07b9ef6072dfcecf89e

Patch for the mouse case:
https://invent.kde.org/system/dolphin/-/commit/efbda5eaa74dfe1ed81c2973c0fbcdf5c97666dc

Will be in next 25.08 maintenance release, 25.08.1.

Any way to make this optional? Because at the moment, it is annoying enough that I downgraded to 25.08.0 for the time being.

(In reply to NecRaul from comment #13)
> Any way to make this optional? Because at the moment, it is annoying enough
> that I downgraded to 25.08.0 for the time being.

this is very annoying indeed and makes for extra work: one extra ESC press for every folder I create with Ctrl+Shift+N to make sure I have nothing selected. or alternatively check for a few seconds if anything is selected in the potentially thousands of subfolders my dolphin currently displays. 

And for a time I was going nuts because creating folders seemingly stopped working until I noticed hundreds of empty folders in  folders that were randomly selected at that time

Is being discussed in https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209

Would having a button "Create another folder" or a shortcut from when the dialog is opened help ?

Arguably Ctrl+SHIFT+N / F10

As I suggested in https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/15

A setting might be necessary unfortunately as users expectations vary apparently. But adding an option should be last resort.

(In reply to Méven from comment #15)
> Would having a button "Create another folder" or a shortcut from when the
> dialog is opened help ?
> 
> Arguably Ctrl+SHIFT+N / F10
That would be pretty accommodating. One could disable the initial shortcut and set the new action to the previous shortcut and continue as if nothing changed.

I should clarify as I made my comment before reading the discuss thread, I want a button that creates a new folder in the current directory regardless of whether or not something is focused. In the example given by OP in the discuss thread, this new button wouldn't create ~/1cat/2dog and ~/3pig but ~/1cat, ~/2dog and ~/3pig even if one of the folders were focused.

(In reply to NecRaul from comment #17)
> I should clarify as I made my comment before reading the discuss thread, I
> want a button that creates a new folder in the current directory regardless
> of whether or not something is focused. In the example given by OP in the
> discuss thread, this new button wouldn't create ~/1cat/2dog and ~/3pig but
> ~/1cat, ~/2dog and ~/3pig even if one of the folders were focused.

OP's take on this. The users who now complain got used to the bug and considered it a feature. Don't try to reinvent the UX wheel. The feature you need was already there. After you right-clicked or selected something you can still right-click the background in between to focus their parent or you can click the background to unselect any sub-folder. It is a bit more complicated in "Details View Mode" (Ctrl+3). I noticed that there the beckground is in the left margin or under the end of the list.

(In reply to René from comment #18)
> OP's take on this. The users who now complain got used to the bug and
> considered it a feature. Don't try to reinvent the UX wheel. The feature you
> need was already there. After you right-clicked or selected something you
> can still right-click the background in between to focus their parent or you
> can click the background to unselect any sub-folder. It is a bit more
> complicated in "Details View Mode" (Ctrl+3). I noticed that there the
> beckground is in the left margin or under the end of the list.
I asked for a toggle that would allow the previous behavior to remain possible, and the response I got instead suggested adding a new feature/button/command for that old behavior. Your argument feels strange to me, because I just upgraded to 25.08.2 to test it, and the UX wheel you’re talking about is still inconsistent and wrong. I can copy or cut a file, select a folder, try to paste and it won’t paste into the selected folder. I can press F10 > Create New > Folder and it will create it in the current directory, not the selected one. You know why? Because paste (just like create) has always been meant to work for the CWD, not the selected folder. If anything, I'd say the behavior you were expecting seems like a bug rather than a feature but I digress. I use my keyboard and not my mouse, so even in Details view mode it's easy for me to unselect whatever is selected by pressing Escape and making a new folder in CWD with a shortcut, that isn't the argument I'm making however. Fact of the matter is, this new fix hinders me from working at the speed which I'm used to. As I mentioned earlier, I am for making this behavior optional or as Meven suggested, making a new button entirely. I want to be able to create a folder in the current directory, regardless of whether something is selected or not using a keyboard shortcut.

(In reply to NecRaul from comment #19)
> I asked for a toggle that would allow the previous behavior to remain
> possible, and the response I got instead suggested adding a new
> feature/button/command for that old behavior. Your argument feels strange to
> me, because I just upgraded to 25.08.2 to test it, and the UX wheel you’re
> talking about is still inconsistent and wrong.
Yes, you are right, I just tried 25.08.2 creates in the correct context when you use Ctrl+Alt+N. However F10 opens the context menu and still ignores the context when you navigate to Create > New Folder with the keyboard arrows. So it is half fixed. Hereby I changed the status accordingly.

https://bugs.kde.org/show_bug.cgi?id=510757

Hi Everyone, 

I noticed a funny behavior in Dolphin v25.08.1. The commit related to this issue has been back-ported from Dolphin v25.08.2 in https://github.com/KDE/dolphin/commit/65bb95f50ed591c8e5c7b07b9ef6072dfcecf89e

So now the Ctrl+Shift+N keyboard shortcut produces a really interesting result :)
Please check my test scenario below.

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. 

Actual:
```$ tree test
test
├── 1
│   └── 2
├── 3
│   └── 4
└── 5
    └── 6


Expected:
$ tree test
test
├── 1
├── 2
├── 3
├── 4
├── 5
└── 6

(In reply to Méven from comment #11)
> Git commit 65bb95f50ed591c8e5c7b07b9ef6072dfcecf89e by Méven Car.
> Committed on 01/09/2025 at 11:07.
> Pushed by meven into branch 'release/25.08'.
> 
> Make create folder use selected directory !1026
> 
> This change makes `Ctrl+Shift+N` behavior consistent with right-click
> context menu:
> - If a single directory is selected, create inside it
> - Otherwise, create in current working directory
> 
> 
> (cherry picked from commit 24d859cf19e90fa22ed687b36a68231625c1bd80)
> 
> 900d5d8f Make F10 create folder respect selected directory
> e5ebe618 Apply 1 suggestion(s) to 1 file(s)
> 
> Co-authored-by: lzwind lzwind <liuzheng@uniontech.com>
> 
> M  +20   -2    src/dolphinmainwindow.cpp
> 
> https://invent.kde.org/system/dolphin/-/commit/
> 65bb95f50ed591c8e5c7b07b9ef6072dfcecf89e

This should never be the default behaviour. If I want a folder created inside a subfolder, I will open that subfolder and then create the new sub-subfolder. All file managers work like that, and for good reason! Currently, this situation happens:
- have folder 1 open in Dolphin
- select subfolder 2
- click on Dolphin's "create new folder" button in the toolbar and name the new folder "3"
The result is that 3 is a subfolder of 2, rather than of 1. This is entirely unexpected and makes it seem like something is broken. There is no way for the user to know that selecting a folder will make the buttons in the toolbar or the shortcuts, the functions of which are expected to apply to the CWD, actually work on the selected folder.

The right-click menu is contextual by its very nature and gives the user the certainty that the action they are performing applies to the thing they clicked on; keyboard shortcuts and toolbar buttons do not have the same expectation (unless they are selection-specific, like "move to the wastebin" or "cut") and, in fact, never work like that. To give further examples of this: 
- if I click "open terminal", it opens in 1, not in 2
- if I click on "search", it opens in 1, not in 2
- we can take this to the next level: should selecting two folders and then creating a new folder create subfolders in each of them? Why should this case be different? How do I know that it is in fact different?
This change should be reverted as it breaks the basic expectations of how file managers work. It also completely breaks accessibility: if I use the keyboard to navigate between files because using the mouse is cumbersome, I can legitimately expect keyboard shortcuts to behave in a clear, discoverable and consistent way which does not depend on selection. The current behaviour makes it a lot more cumbersome to deal with folder creation for people with accessibility issues.

Join the discussion here: https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/43

After reading through the comments from the developers and the plans for Dolphin regarding Working Directory, I wiped my KDE installation and moved onto something else. Good bye KDE, it was a nice decade with you guys. All the best!

Git commit a9cbac74aafe1ce3c5ec37010b84ea8a40035941 by Méven Car.
Committed on 02/11/2025 at 13:13.
Pushed by meven into branch 'master'.

Revert "Make create folder use selected directory !1026"

This reverts merge request !1035 65bb95f5

This simply made an unexpected behavior change, opposite to most users expectations.
https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/33

Disregarding https://en.wikipedia.org/wiki/Principle_of_least_astonishment (Occam's razor)

Having different behavior when there a folder selected + shortcut, and a folder selected + context menu should be considered different use case.
One has a strong context established, the other has no context from the user perspective.
Related: bug 510757

It re-introduces 508196

M  +2    -20   src/dolphinmainwindow.cpp

https://invent.kde.org/system/dolphin/-/commit/a9cbac74aafe1ce3c5ec37010b84ea8a40035941

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1087

This is a case where a user won't expect the shortcut to be influenced by the selection.
No other filemanager does this, and it confused many users.

The context menu action may instead be tweaked to reflect it is not the same action, changing its text in the context menu to explicitly say "Create sub-folder

Git commit 8d4a3802b690a8e3b43d4390652674579a78f4eb by Méven Car.
Committed on 02/11/2025 at 13:15.
Pushed by meven into branch 'release/25.08'.

Revert "Make create folder use selected directory !1026"

This reverts merge request !1035 65bb95f5

This simply made an unexpected behavior change, opposite to most users expectations.
https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/33

Disregarding https://en.wikipedia.org/wiki/Principle_of_least_astonishment (Occam's razor)

Having different behavior when there a folder selected + shortcut, and a folder selected + context menu should be considered different use case.
One has a strong context established, the other has no context from the user perspective.
Related: bug 510757

It re-introduces 508196


(cherry picked from commit a9cbac74aafe1ce3c5ec37010b84ea8a40035941)

62ad5575 Revert "Make create folder use selected directory !1026"

Co-authored-by: Méven Car <meven@kde.org>

M  +2    -20   src/dolphinmainwindow.cpp

https://invent.kde.org/system/dolphin/-/commit/8d4a3802b690a8e3b43d4390652674579a78f4eb

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1088

(In reply to Méven from comment #27)
> This is a case where a user won't expect the shortcut to be influenced by
> the selection.
> No other filemanager does this, and it confused many users.
Can you give one example of a file manager that does so? For instance does the standard windows 10 file manager have a shortcut beside a context menu to create a folder? It doesn't in the folder itself. It was removed. Is that an example to follow? Now I have to actually enter the folder to create a sub-folder. But it has the Navigation panel. There it does have a context menu and it obeys the context, when the folder is selected or only right-clicked. 

> The context menu action may instead be tweaked to reflect it is not the same
> action, changing its text in the context menu to explicitly say "Create
> sub-folder
This is only needed when you keep being inconsistent about what is context. When you click or right-click you as user, you have selected the context of the actions that follow and you expect the file manager to obey that choice by convention. When sometimes it does, or sometimes it doesn't or when sometimes there is a function or sometimes there isn't (like new folder), then you create chaos and you make users confused and chaotic. In the end they end up defending the chaos because it become norm. I think that is what is happening here. 

The better user interface is the human voice: "goto my home folder and create a new sub-folder  named KDE Bugs" or "create a new sub folder in my home folder named ..." Or an AI that reads your mind and knows what you want before you speak or just forget the whole concept of files; why do you need them at all? But until then you keep the conventions as stable as possible and pass on its philosophy to next generations.

(In reply to René from comment #30)
> (In reply to Méven from comment #27)
> > This is a case where a user won't expect the shortcut to be influenced by
> > the selection.
> > No other filemanager does this, and it confused many users.
> Can you give one example of a file manager that does so? For instance does
> the standard windows 10 file manager have a shortcut beside a context menu
> to create a folder? It doesn't in the folder itself. It was removed. Is that
> an example to follow? Now I have to actually enter the folder to create a
> sub-folder. But it has the Navigation panel. There it does have a context
> menu and it obeys the context, when the folder is selected or only
> right-clicked. 
> 
> > The context menu action may instead be tweaked to reflect it is not the same
> > action, changing its text in the context menu to explicitly say "Create
> > sub-folder
> This is only needed when you keep being inconsistent about what is context.
> When you click or right-click you as user, you have selected the context of
> the actions that follow and you expect the file manager to obey that choice
> by convention. When sometimes it does, or sometimes it doesn't or when
> sometimes there is a function or sometimes there isn't (like new folder),
> then you create chaos and you make users confused and chaotic. In the end
> they end up defending the chaos because it become norm. I think that is what
> is happening here. 
> 
> The better user interface is the human voice: "goto my home folder and
> create a new sub-folder  named KDE Bugs" or "create a new sub folder in my
> home folder named ..." Or an AI that reads your mind and knows what you want
> before you speak or just forget the whole concept of files; why do you need
> them at all? But until then you keep the conventions as stable as possible
> and pass on its philosophy to next generations.

Try Windows' file manager yourself, because you will not believe what other people tell you. Do it in a VM for example. Spend some time with it. Try other mainstream (underlined) GUI file managers as well which is used by the masses.
In my opinion the revert is fully justified and it was the right decision. A change like this requires discussions, arguments, and we should settle down on a direction which is acceptable for most (underlined) of the users of the application.

(In reply to René from comment #30)
> The better user interface is the human voice: "goto my home folder and
> create a new sub-folder  named KDE Bugs" or "create a new sub folder in my
> home folder named ..."

I find it funny that, in your attempt to defend your position, you accidentally ended up saying what everyone else has been saying all along: that you expect to *go in to the folder* before creating a subfolder. If there ever was a damning piece of evidence against your case, this is it!

I think everyone has made good points here. There’s no right or wrong! :)
That’s why adding new options in the settings to adjust the behavior as desired makes sense. It doesn’t really matter what other file managers do, after all, because we already have our own expectations for how it should work. And judging by the length of this and other discussions, it seems everyone has a valid perspective. So in this case, adding a new setting seems like the best way to go.

Adding some other bugs as related because these are all about "what is selected after the action"

Since the change was reverted due to complaints, I think it's clear that the behavior being requested here won't be implemented. Thanks anyway!

(In reply to Nate Graham from comment #35)
> Since the change was reverted due to complaints, I think it's clear that the
> behavior being requested here won't be implemented. Thanks anyway!

Sorry, that wasn't clear, I've been chatting Meven on discuss and got the impression that there was still the intention to resolve this (although the "how" part is still evading us all!)

https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/97

Maybe you meant that, the alternative behaviour should be handled in a different bug? Don't mean to argue, I'm just confused.

(In reply to pallaswept from comment #36)
> https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/97
> 
> Maybe you meant that, the alternative behaviour should be handled in a
> different bug? Don't mean to argue, I'm just confused.

At this point, a new, clean feature request would be best.

Just saw a Discuss thread which referenced this issue in the past tense. For those who didn't get the email notification when I added it to See Also, here is the new bug: https://bugs.kde.org/show_bug.cgi?id=512020

This needs to be addressed.

There was a bug in KIO fixed in 6.21 that helps the context menu case:
https://invent.kde.org/frameworks/kio/-/merge_requests/2041

But the optimal behavior is not yet clear to me.

Please give your feedback on the poll:
https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/114

The conversation is best continuing in https://bugs.kde.org/show_bug.cgi?id=512020

https://invent.kde.org/system/dolphin/-/merge_requests/1088 undo the revert

Git commit 60e109632fd63b335ca1cc037c5d5c3e291349f5 by Méven Car.
Committed on 21/11/2025 at 13:25.
Pushed by meven into branch 'master'.

context menu: use selected item as containing folder for New file menu

Use current view url as fallback.

Don't update the selection after a directory is created, except if there
was no selection.
Related: bug 512020

M  +16   -2    src/dolphinmainwindow.cpp
M  +2    -2    src/views/dolphinnewfilemenuobserver.cpp
M  +1    -0    src/views/dolphinnewfilemenuobserver.h
M  +80   -1    src/views/dolphinview.cpp
M  +9    -0    src/views/dolphinview.h

https://invent.kde.org/system/dolphin/-/commit/60e109632fd63b335ca1cc037c5d5c3e291349f5

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1112

Git commit 7820764be3ec4eadbb9079b688566b2c0fdfac40 by Méven Car.
Committed on 21/11/2025 at 14:57.
Pushed by meven into branch 'release/25.12'.

context menu: use selected item as containing folder for New file menu

Use current view url as fallback.

Don't update the selection after a directory is created, except if there
was no selection.
Related: bug 512020


(cherry picked from commit 60e109632fd63b335ca1cc037c5d5c3e291349f5)

Co-authored-by: Méven Car <meven@kde.org>

M  +16   -2    src/dolphinmainwindow.cpp
M  +2    -2    src/views/dolphinnewfilemenuobserver.cpp
M  +1    -0    src/views/dolphinnewfilemenuobserver.h
M  +80   -1    src/views/dolphinview.cpp
M  +9    -0    src/views/dolphinview.h

https://invent.kde.org/system/dolphin/-/commit/7820764be3ec4eadbb9079b688566b2c0fdfac40