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

Riccardo Robecchi <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #23 from Riccardo Robecchi <[email protected]> ---
(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 <[email protected]>
> 
> 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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to