Bug 508196

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

I was of the opinion, that this was resolved. However, after my last update of KDE plasma, the bug is back again?

New folders should not be created inside the currently selected folder.

Please do fix it.

$ cat /etc/*release*

DISTRIB_ID=neon
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="KDE neon User Edition"PRETTY_NAME="KDE neon User Edition"
NAME="KDE neon"
VERSION_ID="24.04"
VERSION="User Edition"
VERSION_CODENAME=noble
ID=neon
ID_LIKE="ubuntu debian"

$ plasmashell --version
plasmashell 6.5.4

(In reply to kde.org@human.li from comment #44)
> I was of the opinion, that this was resolved. However, after my last update
> of KDE plasma, the bug is back again?
> 
> New folders should not be created inside the currently selected folder.

Yes, this is indeed back again T_T

And what's worse, sometimes when you realize the folder you just created has been created elsewhere, and click the empty parts to de-select, and then create a folder again, Dolphin hangs using 100% CPU.

To create multiple folders in the current working directory: not working anymore in Dolphin v25.10.0. 

I have to press the damn ESC key every single f*cking time after a new folder is created. 
The behavior went from random to consistently bad. 

At this point I have grown extremely frustrated by the developers and the complete lack of UX/UI skills.

(In reply to gggeri91 from comment #47)
> I meant Dolphin v25.12.0, sorry, I can no longer follow the amount of
> incompetence.
You're not motivating anyone to give you any fixes to your problems.
You should remember people are working on this as a matter of love, not money, and they certainly don't owe you anything.

I frankly do not understand the reasoning here. There are exactly *three* people advocating for the change introduced here, while literally *everyone else* is saying that this is not a good change and that it breaks the UX. Why do it? Cui prodest?
This introduces a whole load of issues for no benefit. We are talking about changing the UX for a use case which is the niche of a niche of a niche. It's like razing a city because you want to plant a tree in your backyard.
@Méven, you yourself wrote (here: https://bugs.kde.org/show_bug.cgi?id=512020#c4): "But the optimal behavior is not yet clear to me." I would argue that, simply put, there isn't. Nobody, here or on Discuss, has been able to provide one, because there isn't: changing this creates a whole list of changes which completely alter the UX and make it unintuitive at best, and unusable at worst. The simple solution is to revert things back to where they were.
Sometimes the best thing is to just leave things alone. You don't need to reinvent the wheel: it has been working perfectly well in its circular form for a few thousand years. Making it square to climb stairs better isn't a viable solution.

Commenting here, because the other thread seems closed ( https://discuss.kde.org/t/slightly-strange-behaviour-in-dolphin/40209/201 )

I was of the opinion that I would have to live with this feature/bug a while longer but eventually the handling  of “new folder in selected folder” would be reverted to a behavior similar to every other environment under the sun (Windows/Mac/Nautilus/Nemo).

So regardless of “selected folder” the “Ctrl-Shift-N”, ”New folder” will be created in the PWD.

For people like me, who use the keyboard (arrow-keys, alt and enter) to navigate folders in Dolphin, the new “feature” is absolutely annoying. There is always some folder “selected”, so folders get created in random places constantly. 

I switch between OS’es and I do not want to constantly remember a unique “KDE/Plasma special case”. But using Plasma and switching a central component like the file-manager to something foreign like Nemo/Nautilus is not easily done and has many side-effects. 

However, the way Dolphin works now is time-consuming and frankly infuriating, so I would appreciate to know what will happen next:

- will dolphin work again as every other file-manager in existence?
- will users be given a choice to disable this unusual, KDE-only behavior in settings?
- are people like me expected to switch to Nautilus or Nemo?

The same tired illogical arguments just keep repeating themselves... I guess now I have to repeat the same explanation here.... Yknow, on the off chance that anyone is actually interested in learning the error of their ways, and assuming people aren't just doing "I think it should work like this and therefore I am correct and will always be correct".

This "all the others work like that, so this should work like that" argument, makes zero sense, is unproductive, and needs to stop. It's like complaining that your B-double truck is too slow and too big to fit in a parking lot at the shopping centre and it should be more like your hatchback, or that your racecar uses too much fuel and should be economic like your hatchback, or that your hatchback is too small to carry a forklift and too slow to win a race. The problem is not the vehicle, it is the false expectations of the driver.

Dolphin is not all those file managers, it does things those file managers can't, it should not act like them, because it is not like them.

> So regardless of “selected folder” the “Ctrl-Shift-N”, ”New folder” will be created in the PWD.

Understand: The "selected folder" *IS* the "PWD". You can't perform an operation in the "PWD" regardless of the "PWD". That makes no sense, obviously.

PWD stands for "Print Working Directory", it is a command, not a location (actually it's not even a command, the command is "pwd"). You mean "CWD" which stands for "Current Working Directory". Using these terms interchangeably was done in the discuss thread for the purpose of continuity but should not leak out of it as it is incorrect.

The 'CWD' is the directory you clicked on to select - not to be confused with the directory in the toolbar up top, which is NOT necessarily your current working directory, if you are working in some other directory, which is a thing you CAN do in dolphin and can NOT do in those other file managers you mentioned, and it is important that you begin to understand that, if you are going to provide meaningful input to this discussion.

The path in the toolbar at the top does not define your working directory. It defines the root of the tree which is visible. The selected objects define your working objects, and if the selected object is a directory, that is your working directory.

It's the same in Explorer. Try it with del or F2, instead of ctrl+shift+n. Try it comparing what happens if you click a file, or a folder, or the empty space in the background. Del = delete the thing I clicked. F2 = rename the thing I clicked. ctrl+shift+n = create a folder in the thing I just clicked. Note that Explorer is limited in its capability to handle subdirectories, so it limits your ability to do this. Note that Dolphin does not have Explorer's limited functionality when working with files and folders below the displayed location. This is the source of your confusion.

On a related note:

>There are exactly *three* people advocating for the change introduced here, while literally *everyone else* is saying that this is not a good change and that it breaks the UX. Why do it? Cui prodest?

https://en.wikipedia.org/wiki/Argumentum_ad_populum
Maybe those three people are objectively correct, and *everyone else is wrong*. That's a thing that can happen, I know that if you're one of the wrong ones, it might not feel fun to realise it, but, it is still a thing. It makes sense that in a population which is largely composed of new users fresh from Windows, those users are likely to be confused by a file manager that actually has what people requested for decades, was added to Explorer - a tree view, that allows them to view and select subdirectories of their location, to use as a working directory.

But one thing that Windows and Explorer users will surely understand, is that using the mouse or keyboard to select an element of the user interface, anywhere in the OS, even outside of the file explorer, is the way for you to tell the computer than the actions you describe (like delete, copy, paste, create new folder, etc) are to be performed with that element as the target. 

For an example, start typing a reply. Select a word. copy it. Does it copy the thing you selected, or does it copy the entire post?

So, when you say that dolphin doesn't act like "everything else", it actually does, if it creates the folder in the place where you selected. Every GUI works that way, and always has. Windows do break that rule for Explorer though, because it doesn't have the tree view. Dolphin does have the tree view, so it makes no sense for Dolphin to act like Explorer.

You're just clicking on the wrong thing and then confused by the computer doing what you told it to do, because you didn't realise that you told the computer to do that, because in the app you're accustomed to, an app with less functionality, you cannot tell it to do that, and when you clicked in the wrong place, it would ignore you. Now that you're using a better app which can do that and doesn't ignore you, but does what you told it, it's throwing you for a loop. 

That's a real problem, nobody is denying that. Everyone wants dolphin to be intuitive. But to make it intuitive to users of an inferior tool, is not something best achieved by simply making Dolphin an inferior tool, too.

So can we have an option to tell Dolphin to create new folder in the root of the tree which is visible wen the CTRL+SHIFT+N keyboard shortcut is used? I guess that should be no problem for such an advanced file explorer program like Dolphin. users of the "Icons" and "Compact" view would appreciate that. At least I don't give a damn about the "Details" tree view, but hey, that is just me.

One does not need to click on the wrong folder, just navigate the file tree with a keyboard in a way how every single other file-manager works, but in KDE Plasma this results in the creation of numerous sub-folders inside some folder or other, resulting in guesswork and wasted time cleaning up the mess. 

It makes zero sense to break user expectations and burden them with more work. 

KDE/Plasma could try to educate users to do it "the way some developer thinks this should work". But honestly, I moved away from the other distributions (which mainly use Gnome) to KDE-Neon exactly *because* I have more choices

(In reply to gggeri91 from comment #54)
> So can we have an option to tell Dolphin to create new folder in the root of
> the tree which is visible wen the CTRL+SHIFT+N keyboard shortcut is used? I
> guess that should be no problem for such an advanced file explorer program
> like Dolphin.

The devs said in the thread you linked, that they didn't want to make an option for this - and that's with good reason. It's easy to end up with an unmanageable amount of things to toggle. 

I only see one reason to need an option here: Explorer users refuse to change their usage to include clicking in the right place. They insist that they should be able to click the wrong thing, and the app should ignore it, but only in this case of subfolder creation, because that's what they are accustomed to. 

If the devs decide it's a good idea to make an option for that, I'm all for it. I like to imagine they know better than most of us, what works. But I can't help but think that users learning how to drive this new type of vehicle, would be a better way, than having a "make my racecar stop being so fast" button.

> users of the "Icons" and "Compact" view would appreciate that.
> At least I don't give a damn about the "Details" tree view, but hey, that is
> just me.

The same logic also applies to those views. In those views, you can't *see* the subfolders, but you can still click on a visible folder in this view, to select it as the target for your operation, and the operation should still occur on that folder. Just like it would if you clicked it and hit F2 or del, it should rename or delete that selected folder; if you hit ctrl+shift+n, it should create a new folder in that selected folder.

You're hitting a keyboard shortcut/clicking a toolbar button/using a context menu, to tell the machine "Do *this* stuff", and you select the item to tell the machine "When you do stuff, do it to *that* thing". 

Attaching images to hopefully describe this better. You will notice that if you try this in Explorer, it does not work like this, because Explorer is inferior and inconsistent. You will get a delete and a rename entry in the context menu, but no 'New' entry to create a folder. However, if you click the empty space, it works the same in both Explorer and dolphin

(In reply to emanon from comment #55)
> One does not need to click on the wrong folder, just navigate the file tree
> with a keyboard

Irrelevant. Mouse, keyboard, footswitch, thumbstick, eye tracker, voice control, script or otherwise, the selection made by the operator, is the selection, which is the target for operations. By whatever means you do it, if you select the folder and create a new folder, it should happen in the folder you selected, because that's what the selection means. Just like how if you select a folder and hit del or F2. If the operator selects the wrong folder, that's not Dolphin's fault.

> in a way how every single other file-manager works

Scroll up. I've murdered this flawed argument enough times that it's clear that anyone still repeating it is just trolling. How every other file manager works has zero to do with this aside from that it's obviously the source of some bad habits and false expectations.

> KDE Plasma this results in the creation of numerous sub-folders inside some
> folder or other, resulting in guesswork and wasted time cleaning up the
> mess. 

That's not Plasma (or Dolphin) doing that. There's no "guesswork", it's not "some folder or other", it happens where the operator told it to.

> It makes zero sense to break user expectations and burden them with more
> work. 

Unless their expectation is the problem and the cause of their extra work, in which case changing those expectations is the obvious solution.
And regardless of what the user expected, the dialog directly tells them exactly what they got, so it comes as no surprise that they've done it wrong.

> KDE/Plasma could try to educate users to do it "the way some developer
> thinks this should work".

Let's not play this off as what it isn't, that's disingenuous. This is not "the way some developer thinks this should work" this is more like "the way EVERY developer EVER has said it should work, and how it does work, EVERYWHERE, including Windows and Explorer". This is a 50+year old UI paradigm that works everywhere and works great. You select the stuff, you do a thing, means you're doing the thing to that stuff. Simple. 

How many of you have filed a bug report against Explorer that you can't right-click a folder and get a 'New...' submenu? Or that if you browse to it by keyboard and hit the app menu key, that isn't an option, or that if you select a folder and hit the new keybind (ctrl+shift+n) to create a folder, it ignores your selection? And yet it behaves as normal when you do something like F2 to rename or del to delete. That's the place where the UI paradigm is broken. Not here. Yet, here you are.

If you say to your Uncle today at Christmas lunch, "Pass the salt" then you've selected the salt. If he passes the salt, you don't complain that he should have passed the pepper. Maybe you wanted pepper, maybe you meant pepper, maybe you expected pepper, but you said salt. Maybe you meant to create the folder in the view directory, so you should have selected it. If you didn't, and you selected some other directory, that's not dolphin's fault.

> But honestly, I moved away from the other
> distributions (which mainly use Gnome) to KDE-Neon exactly *because* I have
> more choices

I mean I have the choice to eat dirt but I won't blame the grass for how it tastes. I'm still waiting for even one single one of you to "Oh whoops, that was pilot error, I could solve this by just like, stop doing it wrong". The fact that hasn't even come into consideration says a lot.

It's the festive season guys, don't you have something better to do? Family? Friends? Dance party? Drinking alone? Church? Volunteering to feed hungry kids? I have a legit excuse to be here, I physically can't get up and go touch grass and I've got the same trolls spamming my inbox with the same arguments that were crushed months ago. If you're not as crippled as me, you've got better things to be doing right now. Go enjoy stuff and let others do the same. The bug will be here next year. And those same arguments will still be wrong, so leave them in the dust where I put them.

Created attachment 187987 [details]
Creation of a new folder occurs within the selection as it should

Showing: 
Three ways to create a new folder - Context menu, keyboard shortcut, toolbar button. Obviously, these should all do the same thing.

Compact view, mouse navigation/selection. Note the subfolder will be created inside the selected folder. As it should be.
Details view, with subfolders visible, mouse-driven. Same.
Compact view, keyboard navigation/selection (no rightclick! Shift+f10 or app menu key for that menu). Note that if the operator does not select a folder explicitly (as shown), the new folder will be created in the view folder, like Explorer does (pink arrow)

(In reply to pallaswept from comment #57)
> Three ways to create a new folder - Context menu, keyboard shortcut, toolbar
> button. Obviously, these should all do the same thing.

And that is a false assumption. Mixing the mouse right click context menu with the keyboard shortcut (CTRL+SHIFT+N) is a mistake. Same goes for CTRL+V, I know you guys want to "fix" that as well. It was just fine for decades, you know? Changing something after decades, without an option to restore the original, is lazy.

Now we know you're trolling for sure, thank you.

(In reply to gggeri91 from comment #58)
> And that is a false assumption. Mixing the mouse right click context menu
> with the keyboard shortcut (CTRL+SHIFT+N) is a mistake. Same goes for
> CTRL+V, I know you guys want to "fix" that as well. It was just fine for
> decades, you know? Changing something after decades, without an option to
> restore the original, is lazy.

+1000.
This new behavior for no reason is insane, and follows no logic.
I can't even begin to count the amount of folders that I've accidentally created OUT OF VIEW with this new "logic".

Whoever came up with this clearly is not much of a keyboard user.

Just a though, pressing Del deletes the selected item, which you SEE happen. Pressing F2 renames the selected item, which you SEE happen.
This new insane behavior of "pressing new folder shortcut creates new folder inside selected folder" produces a new folder somewhere YOU DON'T SEE. I find it fascinating how some people don't see a problem there. Sometimes what is done by 99,9999% of programs, happens to also be the right thing.

I used to love Dolphin, but PCManFM is looking better and better with every comment added here... 🙄

(In reply to JanKusanagi from comment #60)
> (In reply to gggeri91 from comment #58)
> > And that is a false assumption. Mixing the mouse right click context menu
> > with the keyboard shortcut (CTRL+SHIFT+N) is a mistake. Same goes for
> > CTRL+V, I know you guys want to "fix" that as well. It was just fine for
> > decades, you know? Changing something after decades, without an option to
> > restore the original, is lazy.
> 
> +1000.
> This new behavior for no reason is insane, and follows no logic.

I took the time to explain the logic to you several times over. It's clear you're having trouble grasping it, but that doesn't mean it's not there.

> I can't even begin to count the amount of folders that I've accidentally
> created OUT OF VIEW with this new "logic".

At least you're finally starting to recognise this as your accident and not dolphin's bug.

> Whoever came up with this clearly is not much of a keyboard user.

The people who came up with this were ALL keyboard users because this logic was created when the mouse was. It's not "new" as you asserted, and I explained that above, too.

> This new insane behavior of "pressing new folder shortcut creates new folder
> inside selected folder" produces a new folder somewhere YOU DON'T SEE. 

Sometimes, the user wants this. Sometimes, they don't. The computer can tell which it is, by what the user does. You got the result you requested the computer to give, and it complied perfectly. This is operator error. 

If you want to create a folder somewhere you can see, select the appropriate target folder for the view you are using, or, select the view which will display it.

Eg:
Compact view: select the view folder, where you want the new folder to be created, and then tell it to create a new folder there. Then, the new folder will be created in the view folder like you expect, and you will be able to see it.
or
Details view: select whatever folder you like. Then, the new folder will be created in the folder you selected, and you can view it as needed because details view is cool like that.

TL;DR stop doing it wrong and then blaming dolphin and taking a dump on everyone's holiday.

pallaswept: this worked perfectly for DECADES. How could you live with this for so long? Why other file managers do it the way they do? Maybe it has to do something with UX/UI design you clearly lack knowledge of?

(In reply to gggeri91 from comment #62)
> pallaswept: this worked perfectly for DECADES. How could you live with this
> for so long? 

No, it was buggy, that's why this page exists. Obviously by my continued polite responses to your obvious trolling, I'm very patient.

> Why other file managers do it the way they do? 

I answered this multiple times on discuss, and also, directly above in response to your current trolling. Other file managers, including Explorer, handle selection the same way dolphin currently does - everything does. Here, you can start to learn about user interfaces: https://en.wikipedia.org/wiki/Selection_(user_interface)

> Maybe it has to do something with UX/UI design you clearly lack knowledge of?

Obvious troll is obvious. I'm going to put you both in my spam list now, I don't think there's any chance that anybody could mistake your input as being genuine, or worthy of consideration in implementing a solution, so your trolling doesn't pose the risk of breaking this again, so I don't need to respond to ensure that.

(In reply to pallaswept from comment #63)
> (In reply to gggeri91 from comment #62)
> > pallaswept: this worked perfectly for DECADES. How could you live with this
> > for so long? 
> 
> No, it was buggy, that's why this page exists. Obviously by my continued
> polite responses to your obvious trolling, I'm very patient.
> 
> > Why other file managers do it the way they do? 
> 
> I answered this multiple times on discuss, and also, directly above in
> response to your current trolling. Other file managers, including Explorer,
> handle selection the same way dolphin currently does - everything does.
> Here, you can start to learn about user interfaces:
> https://en.wikipedia.org/wiki/Selection_(user_interface)
> 
> > Maybe it has to do something with UX/UI design you clearly lack knowledge of?
> 
> Obvious troll is obvious. I'm going to put you both in my spam list now, I
> don't think there's any chance that anybody could mistake your input as
> being genuine, or worthy of consideration in implementing a solution, so
> your trolling doesn't pose the risk of breaking this again, so I don't need
> to respond to ensure that.

When users start complaining after a change, what does that tell you?

The  KDE/Plasma decision process seems somewhat broken if it's unable to provide a clear answer to a simple question:
 "What is the consensus now?", or "what will happen" with this bug?

- will dolphin work again as every other file-manager in existence?
- will users be given a choice to disable this unusual, KDE-only behavior in settings?
- are people expected to switch to Nautilus or Nemo?

This is a bug tracker and the bug is open and developers will look into it, when they find time. 
Can you please discuss this in a forum like discuss.kde.org or somewhere more appropriate? Thanks!

(In reply to postix from comment #66)
> This is a bug tracker and the bug is open and developers will look into it,
> when they find time. 
> Can you please discuss this in a forum like discuss.kde.org or somewhere
> more appropriate? Thanks!

They know this because they came here from there. They're not here to discuss a bug, they're here to troll.

I don't care for the shit-flinging happening in the comments of this bug report/feature request, nor do I care to participate in a discuss thread as it seems like it's a waste of time. I was happy with the old way and ever since this change was made and I noticed it, I downgraded to version 25.08.0. I tried out different versions over the last couple of days and 25.12.0 seemed to be cause some issue whenever I created a folder inside another folder. I would have to pkill dolphin for it to resolve. The folder would be created but dolphin wouldn't respond. The other version that didn't have this unwelcome change were 25.08.03 and 25.11.80. I'm unsure if it is related to this change dolphin would take a long time to open (and at times change directories) on 25.12.0. I looked at it with strack and it seemed to be futex related.

Regardless, if you want the old behavior back 25.08.0 and below, 25.08.03 and 25.11.80 seemed to be working fine.

I just hope that Dolphin's Development Philosophy will be not forgotten all of a sudden: https://invent.kde.org/system/dolphin#development-philosophy

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

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

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