Slightly strange behaviour in Dolphin

[subject-delta]

I was guided to this discussion from here: https:// discuss . kde . org /t/new-folder-is-created-inside-of-selected-folder/42754 (broken link because of platform rules - interesting that not even internal links are allowed)

IMHO creating a new folder inside a marked folder in dolphin is not a good implementation for several reasons:

• It’s not the overall default on other systems (at least as far as I know) so people won’t be used to this behaviour and won’t expect it (“where is the folder I just created?”)

• You don’t seem to be able to turn it off. Single-click-to-open was the default for Dolphin before 6.0. Whether you liked this or not, you were able to change it in the settings (If KDE only supported single click to open, I would have never chosen it as it does not work with my work style at all. I went with KDE because it’s incredibly customizable and if there is something that simply does not work for me, I can change it). You can also choose what happens when you press Shift while moving files.
  This feature does not seem to changeable. For me this is therefore a bug, not a feature.

• There is no indication what happened how and where. There is no animation for creating the folder and no indication that it was included within the marked folder.

• When you want to create a new folder (eg. “new folder”) that does exist in the selected folder, but not in the folder you are, you can not create the folder and dolphin gives you an error message, but for the average user there is no indication why it’s not working in the folder you are currently looking at.
  *A folder with name “new folder” already exists’* - Ahm no, it does not? (see image below)

  

Many people dislike Microsoft because they forcefully include tools like CoPilot and Recall without ever asking who would use it where and why or even giving an OptOut option. You get the “feature”, like it or not.
I think implementing such a behaviour is equally wrong if you don’t have a clear and easy way to turn it off. The best spot for such a toggle would IMO be at the position where you control single/double click to open and (Shift+)click&drag to move

[ben2talk]

@subject-delta

IMHO creating a new folder inside a marked folder in dolphin is not a good implementation

I disagree with this - but the text ‘create new folder’ is ambiguous and doesn’t tell you where it’s going to go…

So if the text was contextual, if you pressed your shortcut - a choice should be offered ‘create folder inside selected’ or ‘create folder in view’… and then possibly the option to set ‘always do this’… and you’re right to point out the biggest paper-cut with this method, you don’t know the folder was created unless you enter the selected folder, so… why not just let people enter the folder before they can make a new one inside?

This would fix the bug ‘ignores the selection’ as well as the new bug ‘creates folder out of view - inside selected folder’.

[amilias]

@ben2talk

I disagree with this

Why, though? You wrote yourself just a bit earlier that you’d rather enter the directory and create a new folder in view. Your proposal seems like a lot of work to make something optional that no one so far has come up with a reason as to why it should even exist other then “some people might want to do this, who knows”. And I do agree with the Dev stance that not everything needs to be an option (I just don’t agree with the execution in this instance).
And anyway, if you really want to create a subfolder in a folder out of view you already have the very existing option of right-clicking the folder and “create new” (an action much more deliberate than just having a folder selected, if you ask me) or use the old behavior and type the path with slashes.

[ben2talk]

I think you should be able to do with the keyboard the same you do with the mouse and create a subfolder.

[skyfishgoo]

@subject-delta

There is no indication what happened how and where. There is no animation for creating the folder and no indication that it was included within the marked folder.

@subject-delta

A folder with name “new folder” already exists’ - Ahm no, it does not? (see image below)

the answer is in your screen shot

the dialog box is telling you where it is going to create the new folder, and because you have name selected it is trying to create a folder with the name new folder within that selected folder.

if you navigate to that folder you will probably find there already exists a folder with that name, hence the error message.

this is exactly the same behavior you would get if you chose “create new… “from the context menu when you right click on the folder name.

what i’m hearing is that you would rather Ctrl+Shift+N create a folder only in the current view and not within a folder, whether it is selected or not.

that splits the create a folder function into two modes depending on if it was evoked by the shortcut keys or if was evoked from the context menu.

is that what you would rather see?

[Lenry]

@skyfishgoo

the dialog box is telling you where it is going to create the new folder

I can assure you that nobody, literally nobody is reading that, while using it.

[skyfishgoo]

if they were separate functions you would be able to:

Ctrl+Shift+N with the keyboard, or pick the create a folder icon from the tool bar and make a folder in the current view.

right click a folder and create a folder out of view using the mouse in the context menu, or navigate to the context menu using the keyboard using F10 and activate it that way.

but funny story: i just installed the flatpak version and tried using only the keyboard to access the context menu and guess what?

**
it ignores the selection and only creates the folder in the current view!!!**

my brain has gone smooth over this.

[ben2talk]

Haha I totally missed that… maybe it should be slightly more prominent - but for sure, that’s good.

It doesn’t bother me now, at least it’s consistent now - always check what’s selected or just hit Escape to be sure… so now the main bug is with most keyboards only having Escape in the far top right corner.

I did a fair bit of work modifying the behaviour of my modifier keys - especially the Capslock, Shift, Tab and Escape keys…

[subject-delta]

@Lenry

@skyfishgoo

the dialog box is telling you where it is going to create the new folder

I can assure you that nobody, literally nobody is reading that, while using it.

I can not add anything more to this as it is exactly on point.

@skyfishgoo

what i’m hearing is that you would rather Ctrl+Shift+N create a folder only in the current view and not within a folder, whether it is selected or not.

Exactly.

@skyfishgoo

that splits the create a folder function into two modes depending on if it was evoked by the shortcut keys or if was evoked from the context menu.

is that what you would rather see?

Yes, even it being optional as config setting (If you click you know what you buy into).
I have never used right click on a folder to create a new folder within an existing folder and I never will be.
From your words the split of modes was the default for a long time now. I didn’t see any people rattling at the gates for it to be fixed as the behaviour being a buggy mess otherwise.

I do not want a “feature” (that - again - I perceive as nothing else than a bug) being forced down my throat because other parties may see it as consistent with some other feature.
That change forces me to adapt my workflow to something that I didn’t ask for; didn’t want, don’t want and never will want; and that I can not even turn off.

If I ever want or feel the need to buy into such a developer-customer relationship where I am forced to follow whatever the developer thinks as the best mode without giving the user a choice, I buy an Apple device.

Again: I’m not against the behaviour as such and I’m not against it being the default.
What I’m strongly against is that I can not turn it off, implying that I’m not being viewed as mature user who knows what they do and do not like and who is not able to judge what feature fits their workflow.

[ben2talk]

@subject-delta

What I’m strongly against is that I can not turn it off

Yes, this is about right… unless it’s going to be made a really disruptive notification with an option to disable the notification and continue by setting an option…

It’s not something I remember doing myself - I always enter a folder to create something inside, but I understand that context clicking ON a folder is different - and that should create a subfolder.

[skyfishgoo]

@subject-delta

I have never used right click on a folder to create a new folder within an existing folder and I never will

ok.

@subject-delta

I didn’t see any people rattling at the gates for it to be fixed

the bug report that started this whole churn was about exactly that.

specifically the context menu (that you never will use) showing Ctrl+Shift+N as the keyboard shortcut when using the keyboard shortcut produced a different result.

the easier way to resolve the bug report would have been to simply remove the text from the menu and let the actual function code alone.

but here we are after (god forbid) someone actually tried to make a go of bettering the code.

i think the good faith efforts to make this work should not be so harshly dismissed.

[subject-delta]

@skyfishgoo

but here we are after (god forbid) someone actually tried to make a go of bettering the code.

May I remind you about Deuteronomy 12:32: “See that you do all I command you; do not add to it or take away from it.” (ref)
I don’t want to say that you invited the plague with this … but you kinda did
Revelation 22:18: “If anyone adds anything to them, God will add to that person the plagues[…]”(ref)

So actually god did forbid to change the source code. And who says the plague has to be a dead first born as it can also be a grumpy user…

All jokes aside.

@skyfishgoo

@subject-delta

I didn’t see any people rattling at the gates for it to be fixed

the bug report that started this whole churn was about exactly that.

What I meant with people rattling at the gates is that I never saw it on any list named “Top 10 Problems with KDE” or something like it.

@skyfishgoo

i think the good faith efforts to make this work should not be so harshly dismissed.

I don’t want to dismiss any edit done in good faith.

During my evening run I took the time to think about what I disliked about the change and boil it down to an abstract description that is as short as possible:

The edit changed a (1) basic and fundamental feature with (2) no indication of the change or it’s effect and (3) no other option but to comply.

(1) IMO there are only very few functions in a file browser that I would call basic or fundamental. Creating folders is definitely one of them. Moving and deleting folder/files would be other ones. Renaming a folder/file would probably come in fourth, but it’s not used as often as the first three. If you change the behaviour of such a basic feature, you have to be very careful just by the fact of the feature being at the very base of user interaction. I’m not saying that it is forbidden to make changes to it, but that even small changes can have a large impact for the entire user base as it’s not just about creating the folder, but also how this action behaves (eg. Ctrl+Shift+N creates a new folder and auto selects it. I could press ESC or Ctrl+Space but this would double the required user inputs to create more than one folder as you would have to unselect after each new folder).
An example from current development would be uutils/coreutils (GNU coreutils rewritten in Rust). Some people are very skeptical about this as it touches software that is very basic and fundamental to every distribution and the change has the potential to break a lot of other things just by the fact that it touches something at the very base of a running system.
A KDE example: Moving files can now also done with Click+Drag. The default still is Shift+Click+Drag, but the option allows you to configure it to your liking.

(2) There is no indication that there is a new folder inside the existing folder. No animation, no sound, no KClippy pointing or KNavi giving you a hint what happened. This would probably be the same as creating a new folder as hidden folder (“.new folder”) and hiding such files by default. The average user has no indication what happened and wonders why it does not work and the folder does not exist (in their views window) either.

(3) This one is the most important part of all three. As said: It’s not about the change. And it’s not about it being the default. My displeasure is based on that I can not choose, that there is no other way to accept what you did not ask for.
I heavily dislike the default KDE UI bouncy cursor animation when you open a file. A small element, but IMHO this is just a childish feature that does not belong into a professional workspace. But I have absolutely no problem with it existing or it being the default as I can quickly disable it after a websearch.
Other examples:

• I once suggested to change the default behaviour of a hotkey to a different FOSS project and the request got rejected quite quickly as it would break the workflow people are used to. There was no discussion about being better or worse or more or less in line with other projects that have similar functionality. It was strictly about changing the default behaviour. However, having the feature as option in the settings was no problem at all.
• iOS 26 got a new UI (“liquid glass”). For some reason panels have to be transparent now and you do not even have the option to turn it off. On my company phone (where I had to upgrade to iOS 26) I now have a login screen where in some areas I can’t even see the letters on my virtual keyboard or the password typed. The transparent UI (that I already set to it’s most opaque setting) shows white letters on white parts of my background. For some users this is may the blessing they always wanted, for me it’s just a liquid ass in my face that I can not remove. Furthermore the even more bouncy UI makes me feel as if I had stolen the from a child in kindergarten.
• (Another example from the industry) The code for Redstone in Minecraft is known to be buggy and not work as intended. Yet, it is not changed as this functionality is used in many builds by many different people and a change in this system would break their builds.

An idea for a real life scenario that strikes (1), (2) and (3): All the sudden, you now have to turn your key in a mechanical lock into the other direction to lock/unlock a door. Very small change, but it breaks muscle memory that many people have internalised throughout their entire life.

@skyfishgoo

this work should not be so harshly dismissed.

I never wanted to dismiss you work. If you had the impression that I attacked or wanted to attack you personally or your work, I want to apologize for it.
I do not think that you made the change with malicious intent or to directly discomfort users.

I rather re-formulate my comment to a feature request to include the old way as selectable option. My suggestion for places to include such an option are listed below, but I’m also fine with any other solution as long as I have the choice.

1. In the main settings app in the same location where single/double click to open is located
2. If this setting is too miniscule for such a place: Somewhere in Dolphins own settings.
3. Or if it’s actually only about the keybinding: A different entry for the key binding in the settings app where you can choose if the keybinding should create a new folder in the current view or the selected folder.

Lastly I hope my wall of text was not unbearable long

[amilias]

Very good write-up, I agree with most of this.

But as for changing the default: other than breaking workflows for existing users, it should also be considered if the change actually improves the workflow for new users, and I argue this change does not. Because, as you pointed out, creating a folder in a subfolder without visual feedback is very confusing and the act of creating new folders via shortcut has become more complex because users have to be more careful what is selected.

So far, the only valid “pro” reason for this change is consistency with the context menu, which allows this action. I argue this is a very niche use case, while creating folders in the current directory is a main one. So this change sacrificed the usability of a main feature in favor of a niche one, leading to a decline in the general user experience.

In a different thread yesterday it was “discovered” how there’s two shortcuts for opening a terminal window: Shift+F4 always opens in the current directory, while Shift+Alt+F4 opens in the selected folder. There’s also two different Buttons to add to the Toolbar. While I’d still argue the second one is mostly unneeded, this is the only way I would consider adding such a change for people who want this.

[subject-delta]

A small note as some users will transition over from Windows:
The default behaviour is that the new folder is created inside the current view regardless whether a folder is selected or not.

I’m not arguing that we should copy Windows, but that some users coming over from Windows will be confused as they simply will not be used to this behaviour.

[ben2talk]

@amilias

creating a folder in a subfolder without visual feedback is very confusing

Well, ‘creating a folder in a subfolder without visual feedback’ is indeed a very confusing statement.

So perhaps we should argue, instead, that for this ‘change’ it might make sense to make the confiruation dialog a little more potent…

Looking at Krusader now, hitting F7 creates a new folder… if ‘Tidy’ is selected, we have two ways of creating a folder. 1. Inside Tidy (Tidy/TidyOne) or 2. Inside PWD (Simply edit ‘Tidy’ to be ‘TidyOne’).

This means the default is to create a folder in the current view, but if a folder is selected, then it’s name appears in the ‘create new’ dialog so you can add a slash to create your subfolder.

Back to your initial statement ‘creating a folder in a subfolder’ is confused, because what you will be creating with the / is a subfolder which by definition goes in a folder.

[tmoerschell]

After updating to 25.12.0, the “new” behavior is back (introduced by context menu: use selected item as containing folder for New file menu (7820764b) · Commits · System / Dolphin · GitLab ). Seemingly after discussion in Bug 512020.
I do not want to raise any more points, they have already all been made multiple times. I must say however, that I am in “CWD context” camp for keyboard shortcuts and that I will revert that commit for myself pending a solution. I don’t have a specific use case with multiple folders or anything fancy, just habit and expectation. I use the selections to cruise around the filesystem and don’t really have much focus attached to it when I perform an action in the current view.

Since it seems we cannot make everyone happy by going one way or another, wouldn’t it be a good case for a configuration option (Ctrl + Shift + ,)? A simple checkbox or radio buttons that would let users choose if keyboard shortcuts follow:

• The context menu of the the selected item first, when an item is selected (camp “new”)
• Or the context menu of the current working directory first (camp “old”)

I’m trying to be precise with wording by using "first”. Some actions (like copying a file or folder, or undo redo) are present only in one of the two context menus, and should be available in either situation.

Such a setting would allow for improved consistency in both cases. For example, copy pasting an item currently always does so in the current view. This is how I like it, but not consistent with the “new” behavior. The directory context menu has an entry for “paste”, though no keyboard shortcut. One could argue that when pasting something with a directory selected, it should be pasted into said directory. I’d understand this, but I deeply crave being able to continue as it is now. Another example is Alt + Shift + F4, which uses the selected directory, not consistent with the “old” behavior.

Maybe a unified choice could make the experience better for everyone?

[skyfishgoo]

@subject-delta

What I meant with people rattling at the gates is that I never saw it on any list named “Top 10 Problems with KDE” or something like it.

i would venture to guess there are more than 10 bugs at bugs.kde.org, they can’t all be rock stars

@subject-delta

If you change the behaviour of such a basic feature, you have to be very careful just by the fact of the feature being at the very base of user interaction.

i agree, and the basic function did not change… specifically, if you navigate to a folder and use Ctrl+Shift+N, a new folder is created in the current view exactly the same as it always has.

the issue stemmed from what happened next … specifically, it leaves the newly created folder selected as it always has (probably a different part of the code).

the change called for Ctrl+Shift+N to recognize this “user intention” and act on it… that was the new part, and resulted in the emergent behavior (unintended, i’m sure) that is the subject of this thread.

one possible fix is to NOT select the folder automatically after creation, which keeps your use case intact… specifically, each Ctrl+Shift+N creates a new folder in the current view, just as before.

but there exists another time honored use case here as well… specifically, that of wanting to navigate to the new folder after creation, which would now require a user to select it first.

so one way or another some diehard was was going to be unhappy about having to touch another key to do what they wanted.

the only way i see to satisfy both use cases is to split the baby and keep Ctrl+Shift+N off the context menu and have them be separate functions that behave differently and produce different states in the UI… but this leads to more code and makes dolphin harder to maintain.

no offense was taken by me for sure – i’m not a developer – but i’m just trying to visualize the best outcome for this change.

[Slater91]

@skyfishgoo

the issue stemmed from what happened next … specifically, it leaves the newly created folder selected as it always has (probably a different part of the code).

the change called for Ctrl+Shift+N to recognize this “user intention” and act on it… that was the new part, and resulted in the emergent behavior (unintended, i’m sure) that is the subject of this thread.

Here’s a counter example. I navigate to the Documents folder. I enter the PDF folder. I then go back to the Documents folder, and create the “PDF for work” folder. Since the PDF folder was selected, the new folder is created inside it.

I’m sure we can think of a million other examples where this new workflow breaks expectations. In this push for an imagined “consistency”, we need to reinvent how the whole file manager works. This is not tenable. And, as @amilias was saying, no actual use cases (which aren’t extremely niche) have been brought forward.

Apart from two or three people, everyone is saying that this is a negative change. All of this was introduced because the right-click menu allows to create files and folders inside a folder. I say that we need to use Ockham’s razor: let’s remove that option from the right-click menu. It’s the easiest and cleanest solution which does not require to re-engineer everything else around it. Just to be clear: I use it quite extensively, so I would be the first to be impacted by it and I’m not saying this as just another “oh, someone else will lose functionality I don’t care about, so it’s fine”. I just struggle to find a logical, rational reason for re-architecting everything else around this thing. It’s like tearing down the whole building because you don’t like the walls in your flat.

[ben2talk]

@Slater91

Here’s a counter example. I navigate to the Documents folder. I enter the PDF folder. I then go back to the Documents folder, and create the “PDF for work” folder. Since the PDF folder was selected, the new folder is created inside it.

This is not true.

Entering the Documents folder, I can enter the Notes folder… then I can move back up to Documents and create a new folder… the Notes folder is NOT selected on returning to the Documents folder, it is merely marked as the active folder.

I would have to actively select it (maybe by hitting the spacebar) if I want the new folder to go in as a subfolder.

It is worth testing the truth of each and every statement as you make it, because otherwise the conversation is just a confused mess… For sure you can ‘think of a million examples’ but what we actually need to do is to simply express very real and practical examples.

There are people expressing this as a negative change, nearly every change made in software is initially viewed with a very negative reaction before being accepted and often understood to be a big improvement. Right now, testing is tough because Dolphin is freezing and I’m waiting for Mevin’s recent merge to come through (maybe this week if we’re lucky).

[skyfishgoo]

@Slater91

I navigate to the Documents folder. I enter the PDF folder. I then go back to the Documents folder, and create the “PDF for work” folder. Since the PDF folder was selected, the new folder is created inside it.

i cannot verify this using the dolphin 25.10.0 (flatpak).

navigating up from a folder using either alt+up or the back navigation button does not result in the previous folder being selected, only focused.

Ctrl+Shift+N then creates the folder in the current view as expected.