Whatever the solution may be, please do not change the _default_ behavior of the CTRL+SHIFT+N keyboard shortcut.

Actually this is not a bug. You should open a feature request to introduce a new option to change the behavior of the keyboard shortcut, or ask for a second keyboard shortcut.

This has been confirmed intentional already: https://bugs.kde.org/show_bug.cgi?id=508196

In the context menu item is marked Ctrl_Shift_N which has slightly different behaviour and the focus is confusing for some...

If I right click a folder, I expect to create a folder inside it (unless I right click the background). 
- This makes PERFECT sense because the context menu is explicitly tied to the item you clicked. It’s a “do this here” action with a mouse.

However, GLOBAL shortcuts apply to the current view, not a specific item.  If they acted on the selected folder, it would feel wrong... and what if two folders are selected? what if nothing is selected, simply active?

I feel the SAME would apply to the 'global shortcut' Ctrl_Shift_N, which I feel 'naturally' should create a folder in the current view (PWD).

These are, I believe, very deliberate patterns developed over many years; I would always expect to select and enter a folder (keyboard) to create a folder inside (just pressing Enter), and with the mouse, enter that folder, then click to create a new one.

The idea that these actions should all mix and match perfectly seems wrong when psychology comes into play.

So perhaps a solution would be to offer two options if ambiguous: 'create new folder' and 'create new subfolder'.

Otherwise the defaults are good.

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

(In reply to Ben Guy-Williams from comment #3)
> If I right click a folder, I expect to create a folder inside it (unless I
> right click the background). 

The background is the view folder, if you right-click the background you *did* right-click a folder.

> - This makes PERFECT sense because the context menu is explicitly tied to
> the item you clicked.

Because you selected it when you clicked. 

The CONTEXT of the context menu, is the SELECTION. That's where it gets that name.

Try selecting one item and then holding ctrl while you right-click another item. Now you have added the second item to the selection and opened a context menu which would perform actions on both of them.

> However, GLOBAL shortcuts apply to the current view, not a specific item. 

Oh yeh? try pressing 'del' or 'F2' or 'enter' or 'ctrl+x' ;)
This isn't a GLOBAL shortcut anyway. It only works within Dolphin, it's LOCAL. But whatever, semantics. 

The actions which the user invokes should be performed using the context the user provided. It's "Take THIS, and do THAT to it". 

> If they acted on the selected folder, it would feel wrong

Some disagree, rightly so, because selecting the folder is the mechanism for the user to define the context to which the context menu will apply... and this is the challenge exactly. How can Dolphin be technically correct without making things confusing for users who find that the technically correct behaviour feels wrong, even though it's objectively right? 

> ... and what if two
> folders are selected? what if nothing is selected, simply active?

The standard ways to deal with ambiguous selections are to use the last selected item (oversimplifying: that's the one which is highlighted and also has a dashed box around it) or where that is not appropriate fall back to a default such as the view folder, or just disable that action under those contexts. Dolphin already does this.

> I feel the SAME would apply to the 'global shortcut' Ctrl_Shift_N, which I
> feel 'naturally' should create a folder in the current view (PWD).

The trouble is that works in Windows Explorer all of the time because it doesn't have Dolphin's capabilities. In Dolphin, the working directory (CWD) is not necessarily the view folder, it might be the selected folder which might be N layers deeper than the view folder. This is a powerful feature for power users, but does bring usability challenges, like this bug.

> The idea that these actions should all mix and match perfectly seems wrong
> when psychology comes into play.

Psychologically the issue is that people will refuse to admit a mistake was carried from a dissimilar application and learn a new way. This creates a challenge where the obvious and technically correct solution might generate a lot of complaints. Because it MUST be the solution that is a mistake, since the USER couldn't possibly be mistaken.

> So perhaps a solution would be to offer two options if ambiguous

This bug report is not regarding any kind of ambiguity though. In the context of this bug report, there's no ambiguity, the user's selection is clear. This bug is about Dolphin ignoring it.

Dolphin already handles ambiguous selection (try selecting two folders and right-clicking (no menu item) or clicking the toolbar button (falls back to view folder)) and if there are problems with that, that probably should be a separate bug linked to this one.

dolphin should recognize the selection when using the shortcut as well as the context menu.

those used to using the shortcut with nothing selected should get the same experience they are already used to, and those used to using the shortcut without regard to what is selected will have to be more careful in their use.

most importantly dolphin should not try to anticipate what the user wants to do next by selecting anything automatically or by changing views... this way those used to working with the shortcut will have the predicable results they are familiar with and those using the context menu will have to navigate to or select the new folder on their own if they want to do further work with it.

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

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 508196

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

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 508196


(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