*** SUMMARY In detail view mode when I create a new sub-folder with context menu, then it is created in the right clicked folder. . However, when in the detail view I select the folder and then use the F10 key it creates it in the present work directory. This I consider unexpected behaviour because F10 does not respect the selected folder. STEPS TO REPRODUCE 1. Set Dolphin in Details View mode (Ctrl+3). Makes it easier to see where the folder is actually created. 2. Right click a folder and click Created New > Folder F10 to create a subfolder 3. The sub-folder is created in side the right clicked folder. Expected behaviour. 4. Click (select) a folder and hit the F10 key to create a subfolder 5. The sub-folder is created in the present work folder (the pwd when you hit the F4 key). OBSERVED RESULT F10 creates subfolder in (F4) pwd. EXPECTED RESULT F10 creates sub-folder in selected folder (consistent with mouse UX). When keyboard operated you move around folder with arrow keys and open folders with Enter. When you don't enter the folder the arrow keys determine which folder remains selected. Just like mouse operated it should then be possible to create a sub-folder without entering the folder. F10 in the context menu suggests that. The present behavior breaks this consistency. When mouse operation respects the selected folder and context menu suggest F10 as alternative, then it should also be consistent with mouse operation. SOFTWARE/OS VERSIONS Debian 12 Linux/KDE Plasma: KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8
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 #46) > 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. I meant Dolphin v25.12.0, sorry, I can no longer follow the amount of incompetence.
(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.
(In reply to JanKusanagi from comment #48) > (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. My problem is the resistance I see from the developers when asking to make the new behavior optional.
But you are right, it was a hot-headed comment from my end, purely out of my frustration. I appreciate all the work done, and I know many of the devs do it in free-time. I just want back the classic behavior, that is all.
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. ***
*** Bug 515583 has been marked as a duplicate of this bug. ***
*** Bug 515929 has been marked as a duplicate of this bug. ***
Is there a scenario where a user pressing Ctrl+Shift+N actually wants to create a folder somewhere else than in the currently visible one? I think this is the problem, the new behavior just don't have any practical use, while the old one had and was intuitive. (In reply to pallaswept from comment #53) > 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. I don't think this analogy works - all these commands (delete, rename, create new) take an argument for the operation and execute it in the CWD. Delete deletes the selected folder in the CWD, rename renames the selected folder in the CWD and create new creates a folder with the chosen name in the CWD. This is how it works in all other file explorers and also in the terminal (rm, mv, mkdir). I saw that you defined "CWD" differently, but in all other tools CWD means the currently displayed directory, not the argument of a command, even in the terminal. (In reply to pallaswept from comment #53) > You're just clicking on the wrong thing and then confused by the computer doing what you told it to do I don't think anyone here is actively selecting a directory and then pressing Ctrl+Shift+N. We're navigating with the keyboard and operate with shortcuts, which inevitable ends up with some directory being selected after the last operation, but that doesn't mean we want to create a subdirectory there, and I don't think there's any common scenario where such a behavior would be useful. (In reply to pallaswept from comment #63) > Obviously by my continued polite responses to your obvious trolling, I'm very patient. pallaswept, you're definitely not polite, you're looking down at everyone you disagree with and treating them as trolls, while not even considering that the world may be more nuanced: > anyone is actually interested in learning the error of their ways > 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? > Now we know you're trolling for sure, thank you. > It's clear you're having trouble grasping it > Obvious troll is obvious. > I don't think there's any chance that anybody could mistake your input as being genuine
Another obvious troll.
I don't see redford's comments as trolling, but as an attempt at providing reasoning for their position on the current behavior. With that said, there is an active merge request to attempt to fix this bug, and further discussion not related to fixing the bug should happen on the forums. Let's everyone take a breath, and remember to treat each other respectfully. Thanks.
Still an issue in Version 25.12.2 of Dolphin. Was this change not meant to be reverted. The confusion around this has been evident. Adding additional layers of checks and verification (do I have a folder selected ; where is this folder being created ; have I visually checked I don't have a folder in focus with either mouse or keyboard) isn't great.
*** Bug 516341 has been marked as a duplicate of this bug. ***
https://bugs.kde.org/show_bug.cgi?id=510166 left me under the impression the new behaviour was to be reverted, but, obviously, it wasn't. The developers appear not sure about how to tackle this. I think that the issue is that Dolphin does things I (and other users like me) cannot see. The mentioned PRs don't seem to address this issue: disabling selection after dir creation (https://invent.kde.org/system/dolphin/-/merge_requests/1137) will complicate some user flows, and reverting the context menu behaviour of using of the selected item as containing folder for new file menu (https://invent.kde.org/system/dolphin/-/commit/60e109632fd63b335ca1cc037c5d5c3e291349f5), while it is a step in the right direction, it will not prevent the hidden dir creation by other means (e.g. keyboard shortcuts). I agree that having the newly created folder should be selected, but, while I like being able to rename it directly, I really don't like not seeing subsequent folders being created. Also, feels funny when having intentionally selected multiple folders creating a new folder operates in the current location, while having unintentionally (like after creating a folder) selected a single folder creating a new folder operates hidden in the newly created folder. The discrepancies leave the user puzzled. Please, remember that the user experience will not be improved by arbitrarily enforced rules, however logical they may be, but by smartly adapting the interface to the user needs. I love KDE precisely because it does this better than any other desktop environment I used (and I used all major operating systems and desktop environments). To me, the best solution would be to group the operations that do not have visible feedback/results on the selected item (e.g. creating new folders) and making this group ignore selections and operate instead in the current visible location.
How https://bugs.kde.org/show_bug.cgi?id=516341 could be marked duplicate if _this_ bug when they want completely different behavior? 1. _this_ wants to create new folders in the selected folder 2. 516341 wants to restore the original behavior as it was before a developer had a mad-hair-scientist moment (Méven) As 516341 describes the Ctrl+Shift+N keyboard shortcut must always create new folders within the current root of the view (current directory).
This bug collects similar bugs of the non-standard handling of folder-creation by dolphin. Dolphin should behave like all the other file managers. That is the reason people continue to open new tickets.
(In reply to emanon from comment #82) > Dolphin should behave like all the other file managers. Obvious troll is obvious.
Created attachment 190283 [details] Nemo also adheres to the selection when creating a new folder Can we please stop with "it should act like all the other file managers" now? We aren't getting any closer to a solution that way, and it's never been valid or true.
(In reply to pallaswept from comment #83) > (In reply to emanon from comment #82) > > Dolphin should behave like all the other file managers. > > Obvious troll is obvious. You can't just dismiss everyone who disagrees with you as a troll. You have repeatedly antagonized people who are raising legitimate concerns about: 1) The newly introduced behavior. 2) The fact that the original post in this thread explicitly referred to Details View, yet the change now affects other views as well. 3) The absence of a clear, final resolution, whether this behavior will remain as is, be adjusted to better accommodate more users, or be reverted to its previous state.
(In reply to pallaswept from comment #84) > Created attachment 190283 [details] > Nemo also adheres to the selection when creating a new folder > > Can we please stop with "it should act like all the other file managers" > now? We aren't getting any closer to a solution that way, and it's never > been valid or true. The attached video does not show the out of the box experience of Nemo. It is therefore irrelevant in this discussion. By default (meaning: out of the box experience) Nemo creates new folders in the current view (not inside the selected folder). Anyone can check it by just booting up the latest Linux Mint iso.
(In reply to NecRaul from comment #85) > (In reply to pallaswept from comment #83) > > (In reply to emanon from comment #82) > > > Dolphin should behave like all the other file managers. > > > > Obvious troll is obvious. > > You can't just dismiss everyone who disagrees with you as a troll. Never have. I dismiss obvious trolls who are repeating the same obvious troll arguments they've spouted when they were obviously trolling all the other dozens of times, since I took the time to give them a clear understanding of what's really happening and they chose to ignore it because they're obviously trolling. > You have repeatedly antagonized people who are raising legitimate concerns No, I have repeatedly addressed those legitimate concerns - something you selectively ignore of course - and antagonised trolls for trolling. > about: > 1) The newly introduced behavior. Is a problem and I addressed it. > 2) The fact that the original post in this thread explicitly referred to Is all I've discussed. > Details View, yet the change now affects other views as well. A uniform solution that's intuitive for everyone and not gimped for everyone to appease users who lack understanding seems like a smart way to do it. > 3) The absence of a clear, final resolution, whether this behavior will > remain as is, be adjusted to better accommodate more users, or be reverted > to its previous state. Not up to you or I, that's up to the devs. I'm just trying to make sure that a few trolls pretending they don't understand that this isn't Windows Explorer from intentionally trying to make it as featureless as Windows Explorer for no cause other than to troll people who are using selection like it is supposed to be used. All you've got are false accusations against me and haven't offered anything in the form of a solution other than "it should act like every other file explorer" which as I have demonstrated is nonsensical because Dolphin doesn't work like them, and now I've shown you another one just like it. I sure as heck don't see any evidence of you having spun up 6 different distros looking for inspiration for a solution and references to how other similar apps deal with this. I don't see you taking the time to explain it. I don't see you offering a solution that might actually retain functionality. All I see is a handful of trolls trying to ruin dolphin.
(In reply to gggeri91 from comment #86) > (In reply to pallaswept from comment #84) > > Created attachment 190283 [details] > > Nemo also adheres to the selection when creating a new folder > > > > Can we please stop with "it should act like all the other file managers" > > now? We aren't getting any closer to a solution that way, and it's never > > been valid or true. > > The attached video does not show the out of the box experience of Nemo. Yes it is. I didn't even install it, that's a live ISO. All I did was put it in details mode, which is reflective of dolphin's behaviour which is why it is relevant to this discussion. But you already knew that, you're just trolling. > Anyone can check it by just booting up the latest Linux Mint iso. That's exactly how that video got there.
(In reply to pallaswept from comment #88) > All I did was put it in details mode Exactly. By default, Nemo creates new folders in the current directory. The "subfolder behavior" only occurs after explicitly switching to “Details” view. That makes it predictable and tied to an intentional user action. I find Nemo's implementation reasonable. Your video demonstrates the "Details" view, but if someone wants to see the out-of-the-box experience, here it is: https://snappable.media/video/2026-03-02-23-54-21-Nemo-new-folders.OF4R > Can we please stop with "it should act like all the other file managers" I am using Dolphin v25.08.3 from the Kubuntu Backports PPA which behaves like "any other file manager", I am sorry to break this to you.
Well, being passionate communicates better by being accommodating. I do agree that "Dolphin should behave like all the other file managers" cannot be a valid metric - even if all other file managers would have the same behaviour, which I'm pretty sure is not the case. Good UI products differentiate by better management of the user expectations, not by following the status quo. That being said, I'll always take good things even from Windows File Manager. All this debate sparked my curiosity and took a quick look at several file managers (I'm on Manjaro): 1. Nemo and Windows File Manager hides the folder creation options in the context menu on selected folder. When done by keyboard shortcuts or menu options, it will create the new folder in the current folder (not the selected one). I was not smart enough to activate the tree view in the file panel list view like in pallaswept's video. 2. Dolphin and PCManFM-Qt will create the new folder in the selected folder, regardles of using keyboard shortcuts, menu or context menu options. I kinda like more the way Nemo and Windows File Manager force me to always be in the location the new folders are created. I think I might be OK with Dolphin/PCManFM-Qt's way if the context menu on selected folder would say "Create new folder inside this folder" - although the top menu options are not aware of the context (I think), I presume not many are using them. I'm OK with the behaviour depicted in pallaswept's video because I can see what is doing, which cannot be said about all other views. So, instead of trying to enforce global behaviours, the better solution would be to adopt the least friction behaviour for each view.
Created attachment 190300 [details] Gnome files also adheres to the selection when creating a new folder "like all the other file managers" was never a real thing, and even if it had have been, it never applied to dolphin anyway, because dolphin isn't them.
(In reply to NecRaul from comment #85) > You can't just dismiss everyone who disagrees with you as a troll. Pallaswept must work in a cinema, because he's clearly projecting all the time. I therefore suggest not feeding the troll, as nothing good will ever come of it. He's made it clear that, according to him, we're all stupid and he's the only one who's understood everything. Let's not give him what he wants, which is exactly this sort of attention, and let's not clog everyone's inboxes with further trolling. Maybe he'll decide to start projecting some nice old movie rather than nonsense. Thanks.
(In reply to pallaswept from comment #87) > (In reply to NecRaul from comment #85) > > (In reply to pallaswept from comment #83) > > > (In reply to emanon from comment #82) > > > > Dolphin should behave like all the other file managers. > > > > > > Obvious troll is obvious. > > > > You can't just dismiss everyone who disagrees with you as a troll. > Never have. Starting off with a lie. > I dismiss obvious trolls who are repeating the same obvious troll arguments > they've spouted when they were obviously trolling all the other dozens of > times, since I took the time to give them a clear understanding of what's > really happening and they chose to ignore it because they're obviously > trolling. You are not the authority on what constitutes trolling. The same arguments have been made repeatedly by different people, not because they are trolls, but because the concerns are reasonable. Dismissing them as trolling simply avoids engaging with the substance of what is being said. Throughout this thread, you have focused largely on semantic distinctions, such as CWD versus PWD. While those terms are technically different, that distinction is not central to the issue being discussed. In practical conversation, both can be used interchangeably when the meaning is clear from context. > No, I have repeatedly addressed those legitimate concerns - something you > selectively ignore of course - and antagonised trolls for trolling. The people you keep labeling as trolls have raised legitimate concerns that should be addressed by the developers. Instead, you have dominated the thread while positioning yourself as the gatekeeper of what counts as valid feedback. > Is all I've discussed. You claim to have only engaged in relevant discussion, yet you also admit to antagonizing so called trolls. That behavior does not contribute constructively to resolving the issue. > A uniform solution that's intuitive for everyone and not gimped for everyone > to appease users who lack understanding seems like a smart way to do it. If uniformity is the goal, then a consistent approach would be to extend the behavior currently present in Details View to the other views as well. That idea, much like universal uniformity is stupid. Mouse driven workflows and keyboard driven workflows are fundamentally different, and treating them as identical ignores how people actually use their systems. For example, (AFAIK default behavior) double clicking the background selects all items. That does not mean pressing Enter twice should trigger the same behavior. If multiple folders are selected, should Ctrl+Shift+N create a new folder inside each of them? The previous behavior was intuitive for users. If you have the ability to read, maybe read that "Development Philosophy" that was posted earlier in the thread and try to understand if it's valuable or if it should be removed or changed because you want it to be. > I'm just trying to make sure that > a few trolls pretending they don't understand that this isn't Windows > Explorer from intentionally trying to make it as featureless as Windows > Explorer for no cause other than to troll people who are using selection > like it is supposed to be used. Oh the savior of KDE bug tracker whose many comments were tagged as spam. I guess one of the KDE people must be a troll who has it out for you. > haven't offered anything > in the form of a solution other than "it should act like every other file > explorer" which as I have demonstrated is nonsensical because Dolphin > doesn't work like them, and now I've shown you another one just like it. You have repeatedly misrepresented my position. I have never argued that Dolphin should behave like any other file manager, nor have I said it should mimic them. I do not care how other file managers behave. Please refrain from attributing positions to me that I have not expressed. > I sure as heck don't see any evidence of you having spun up 6 different > distros looking for inspiration for a solution and references to how other > similar apps deal with this. By your own argument, comparing Dolphin to other file managers is irrelevant. So suggesting that I should test multiple distributions for inspiration contradicts your earlier point. > I don't see you taking the time to explain it. > I don't see you offering a solution that might actually retain > functionality. I have already explained my position earlier in the thread, when the behavior first changed. Repeating it here would serve no purpose. I have also proposed a solution before you joined this discussion. If you missed it, that is not my responsibility. Throughout this entire discussion, your posts have been filled with misspellings (blame your gimped hands!), repeated misunderstandings, rambling tangents, and arguments that either miss the point entirely or deliberately misrepresent what others have said. I'll go with the metric that you've set for others and say you are either an obvious troll or along with your physical disability, you also have a mental one.
(In reply to Gabriel Tenita from comment #90) It's good to see someone actually taking a view to resolving this and actually recognising BOTH sides of this. Your post was a breath of fresh air, thank you. > Well, being passionate communicates better by being accommodating. I've always been accommodating. See id you can find anyone who's actually spent as much time as me looking into BOTH sides of this discussion, and taking the time to document it. You might not be aware, and some of it isn't even there any more courtesy of badmins siding with obvious trolls, but this has been ongoing for some months prior to being here, on the discuss forums. And in spite of taking the time out to explain it and try to work toward a solution, all I've had are months of trolls, and moderators saying they aren't trolling, while I have to setup spam filters on my personal email because they spilled over from the forum to here to there. These trolls seems to take great enjoyment in completely ignoring all the things I've said in support of them. Just to pick the first of such supportive comments I see in this thread: > That's a real problem, nobody is denying that. Everyone wants dolphin to be intuitive. But the response is the same like a bad echo in here: 'it should be the same as all the other file managers'. Something I think I've taken more time than I should have needed to demonstrate is inarguably false, because a) dolphin isn't comparable to all the other file managers and b) the other file managers don't even act like that anyway. Like every single post it's the same: > I am using Dolphin v25.08.3 from the Kubuntu Backports PPA which behaves like "any other file manager", I am sorry to break this to you. OBVIOUS TROLLING. It's not even a question. Now, behind the trolls, I'm pretty sure a few people did legitimately get tripped up by this. It's not like Windows, they're fresh from Windows, it's gonna be confusing. It's only fair. My issue isn't that these guys have a problem and find the new behaviour unintuitive and I've never said it shouldn't be a goal to make it intuitive, in fact I've specifically said it should be intuitive for everyone - just to grab two handy examples: > Everyone wants dolphin to be intuitive. > A uniform solution that's intuitive for everyone But like I said before: > to make it intuitive to users of an inferior tool, is not something best achieved by simply making Dolphin an inferior tool, too. And the ONLY solution being offered by these trolls - over and over, without any exception or any effort whatsoever to find a better way to deal with it - and which isn't a real solution because they aren't trying to solve a problem, they're literally only trolling; is "it should act like all the others". It's complete nonsense and the fact that KDE are not only allowing but now encouraging this kind of obvious abuse of actual long-time contributors is just shameful. > So, instead of trying to enforce global behaviours, the better solution would be to adopt the least friction behaviour for each view. That makes sense for users who only use the one view or the other, but we don't all do that. It's actually really handy to have a pane open with giant video thumbnails and another one in details mode for moving said video files around - and obviously it's kinda unintuitive if it's switching behaviour all the time. But ideas for actual solutions are good so don't be discouraged, keep em coming, please, and thank you!
(In reply to Riccardo Robecchi from comment #92) > (In reply to NecRaul from comment #85) > > You can't just dismiss everyone who disagrees with you as a troll. > > Pallaswept must work in a cinema, because he's clearly projecting all the > time. I therefore suggest not feeding the troll, as nothing good will ever > come of it. He's made it clear that, according to him, we're all stupid and > he's the only one who's understood everything. Let's not give him what he > wants, which is exactly this sort of attention, and let's not clog > everyone's inboxes with further trolling. Maybe he'll decide to start > projecting some nice old movie rather than nonsense. > Thanks. Another obvious troll. What contribution to a solution have you made with this post? Nothing, it's 100% trolling.
(In reply to NecRaul from comment #93) > (In reply to pallaswept from comment #87) > > (In reply to NecRaul from comment #85) > > > (In reply to pallaswept from comment #83) > > > > (In reply to emanon from comment #82) > > > > > Dolphin should behave like all the other file managers. > > > > > > > > Obvious troll is obvious. > > > > > > You can't just dismiss everyone who disagrees with you as a troll. > > Never have. > Starting off with a lie. Easy to say its a lie but you can't prove it because you're lying when you say it. You're trolling. Scroll ito your own reply and you can find yourself saying you've never supported this concept and yet here you are opening with it.... I'll remind you when we get down there... > You are not the authority on what constitutes trolling. Nor do I need to be, I just need to be able to tell when I'm reading one, like now. > The same arguments > have been made repeatedly by different people, not because they are trolls, > but because the concerns are reasonable. No, they're not reasonable, and I demonstrated why, severalfold, and even if they had been, just repeating them over and over adds nothing to the conversation other than to bait me, which is exactly what you're doing. > Dismissing them as trolling simply > avoids engaging with the substance of what is being said. Except I've already engaged with substance, repeatedly, for months, and they've given NOTHING BUT TROLLING. And now you're joining in. > Throughout this thread, you have focused largely on semantic distinctions, > such as CWD versus PWD. That's a lie. I didn't focus on it, on the contrary. Let's read that again shall we: > 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. That's it, that's all I said about that. No focus, just a quick explanation for those who were mis-using the term, and left it at that. > While those terms are technically different, that > distinction is not central to the issue being discussed. In practical > conversation, both can be used interchangeably when the meaning is clear > from context. And yet it's clear that you didn't understand what they mean if you're arguing that the view directory is the same as the CWD/'pwd'/whaateveryoucallit, because it isn't, the selection is. > The people you keep labeling as trolls have raised legitimate concerns No they have not. They've repeated that "dolphin should act like all the other file managers" over and over. That's trolling. A legitimate concern would be "wow, I never realised that the selection actually matters here, and it's throwing me for a loop, can we somehow make the UX more intuitive here while not also screwing all the power users?" And I directly addressed exactly that. > Instead, you have dominated the thread No, I've had my inbox dominated by the trolls in this thread who won't just let it sit. I'm just replying to you guys. I'm not dominating anything, I'm just replying. I tried to not reply, and not feed the trolls, and TraceyC did that for me instead. > while positioning yourself as the gatekeeper of what counts as valid feedback. I'm not positioning myself as anything, except for maybe history teacher and target for trolls. I didn't invent selection or the mouse. None of this is new. It's not coming from me. > > Is all I've discussed. > You claim to have only engaged in relevant discussion, yet you also admit to > antagonizing so called trolls. No, not so-called trolls. Trolls. Of course I didn't engage in relevant discussion with trolls, none of you are discussing anything relevant. You're just trolling. What part of this post of yours that I'm replying to, is contributing to a solution? None of it, it's just troll from beginning to end. > That behavior does not contribute > constructively to resolving the issue. It does, it means at least one person is the voice of sanity here and not just an obvious troll trying to ruin dolphin because trolling pallaswept is fun and dolphin seems to matter to him. > > A uniform solution that's intuitive for everyone and not gimped for everyone > > to appease users who lack understanding seems like a smart way to do it. > If uniformity is the goal, then a consistent approach would be to extend the > behavior currently present in Details View to the other views as well. Mightn't hurt. One user on the forums even explained how this could be done without it being unintuitive for you guys. > That > idea, much like universal uniformity is stupid. Mouse driven workflows and > keyboard driven workflows are fundamentally different, and treating them as > identical ignores how people actually use their systems. What about keyboard and mouse driven workflows? Or keyboard OR mouse driven workflows. What about the workflows that use both interchangeably? What about footswitches and mouth straws and eye trackers? There's a whole world of input you've never even thought about. Universal uniformity has functionality you obviously haven't considered. > For example, (AFAIK default behavior) double clicking the background selects > all items. That does not mean pressing Enter twice should trigger the same > behavior. It *does* mean that clicking *or* pressing space should select, and of course, the action a user performs should occur to the selection, because that's literally what it's for. > If multiple folders are selected, should Ctrl+Shift+N create a new > folder inside each of them? Now you're actually asking useful questions. More of this and less of "SamE aS thE oTHeR fiLe ManAgERs" would make this whole bug report a whole lot better. You wanna not get called a troll? Ask actually useful questions like that. Wanna repeat the same exact argument we've all heard literally dozens of times? I'm gonna call you a troll for acting like a troll. Your call. BTW the answer is to use the active selection (the one with the square around it) > The previous behavior was intuitive for users. And it was also unintuitive for users, and that’s the awkward part nobody wants to seem to deal with. It's gotta be "my way or the highway" and its counterproductive. It was intuitive for users who don't understand how selection works. And that’s a lot of users and that’s a real problem. But that doesn't mean it's the right way to do it, at the expense of all the users who do understand how selection is meant to work and find it ....not working. > If you have the ability to > read, Real mature son. > maybe read that "Development Philosophy" that was posted earlier in > the thread Already did of course. > and try to understand if it's valuable or if it should be removed > or changed because you want it to be. No need to change it. This is basic Simon stuff. Simon understands that selection works how it does. He's been a developer for 8 years, he knows that when you click something to select it and then perform an action then the selection is the target of the action. It's pretty basic knowledge. Even Lisa knows this from using MS Word. But nice straw man trying to suggest I'm trying to change the design goals of dolphin just because I am not Fred. Those design goals say it shouldn't be made for Fred, and Fred is the "I don't know how selection works" guy in that crowd. And heck, I'm even trying to accommodate the various trolls pretending to be Fred here, but maybe you're right, maybe all these guys who don't understand selection should just cry more? idk about that but hey this is your argument. > Oh the savior of KDE bug tracker whose many comments were tagged as spam. I > guess one of the KDE people must be a troll who has it out for you. At least one is, yep. Probably more. But thanks for pouring on the sarcasm like a corrupt moderator reinforces your point any at all. > You have repeatedly misrepresented my position. Repeatedly or just the once? Oh yeh it's just the once. But yeh, I did. I hate to break it to you but I'm not exactly taking note of which troll is which. Why would I? And besides, it's kinda ironic for you to complain about my misrepresenting your position while you've just done the same to me several times in a single post. > Please refrain from attributing positions to me that I have not expressed. I will do my best but if you're gonna stand in a crowd of trolls shouting along with them just because you don't like what I'm saying, you're just another one of the trolls. Perhaps if I weren't dealing with so many at once it'd be easier to track who's who. > > I sure as heck don't see any evidence of you having spun up 6 different > > distros looking for inspiration for a solution and references to how other > > similar apps deal with this. > By your own argument, comparing Dolphin to other file managers is > irrelevant. So suggesting that I should test multiple distributions for > inspiration contradicts your earlier point. No it doesn't what are you talking abut. I tested those file managers specifically to prove my earlier point that "like all the other file managers" isn't a real thing, and I clearly succeeded. And taking inspiration from how other distros/OS deal with it doesn't amount to just taking the least-comparable alternative (Explorer) and copying its behaviour verbatim, which is what's been suggested here, over, and over, and over again. > I have already explained my position earlier in the thread, when the > behavior first changed. Repeating it here would serve no purpose. Other than trolling me, and here you are. > I have also proposed a solution before you joined this discussion. If you missed > it, that is not my responsibility. That was not before I joined this discussion. I've been here since the getgo. I just tried to keep this nonsense out of the bugzilla and keep it to the forums, but the trolls are here, and I am replying. I responded to your suggestions and shared one of them, prior to your making them here, if you missed it, that's not my responsibility. > Throughout this entire discussion, your posts have been filled with > misspellings (blame your gimped hands!) The fact that I'm disabled might cause typos, yes. You calling my hands gimped is enough to get you to find out how fast they are if you come to Melbourne, son. , repeated misunderstandings, Not a one > rambling tangents, Where? > and arguments that either miss the point entirely Where? > or > deliberately misrepresent what others have said. Never happened, you're a liar and a coward. > I'll go with the metric > that you've set for others and say you are either an obvious troll or along > with your physical disability, you also have a mental one. Yeh definitely not trolling at all this guy. scum. come at me.
Guys. This is a bug tracker, not a cage match. Bugzilla doesn't have a concept of "locking the thread" to enforce cooldown for people who are getting a bit overheated, so let me be very clear: Anyone who continues posting inflammatory and insulting comments after this point will have their Bugzilla account deactivated. Consider this a formal warning. Thank you in advance for your contribution to keeping bugs.kde.org a civil place for people to do work.
As a keyboard user, these are simply facts: - This behavior of dolphin is new behavior - This behavior reverses the productivity-gain of using a keyboard completely, as one has to constantly press ESC to be save to not have something selected - This is non-standard behavior. Neither nemo, nor nautilus, nor Explorer nor any other file-manager in existence does create folders in selected folders - when using keyboard-shortcuts. They all use the PWD At the moment there is only the choice of pinning dolphin 25.8.3, as I have done - or using another file-manager.
Created attachment 190307 [details] nautilus behavior
Created attachment 190308 [details] nemo behavior
(In reply to Nate Graham from comment #97) > Guys. This is a bug tracker, not a cage match. I escalated off the bug tracker two weeks ago and have not had a response. The opportunity was right there for us to take this off bugzilla. Nobody takes any action, the trolls are empowered, they escalate to direct emails and blatant ableist slurs. I stand up for myself and I get what I said in the email I sent you: This issue has become the "ping pallaswept to troll him until he is silenced, the mods are on your side" show. How am I to have any confidence that the trolling won't just continue given this precedent? (edit: oh look it already did) This ain't right, Nate. Given how far it is from the inclusive image KDE usually projects, I'm assuming it's unintentional, but it sure ain't right. You've got my email if you want to contact me off bug-tracker. I won't accept a warning, I've done nothing wrong, I did everything possible to avoid all this.
Created attachment 190310 [details] nautilus with expandable folders in list view
There seems to be a genuinely different way of using file-managers. As I use nemo, nautilus or even explorer they all do not create new folders in some subfolder but in PWD [1][2] . The video posted above by another user seems actively expand the details view to make it do that [3] (Key: cursor right). This is how nautilus behaves with selected folders normally [4] without explicitly expanding a folder. I also think "all the other file managers do it like this" is indeed a valid argument. I personally want to work in different environments and rely on the fact that on the most basic level like "folder creation" they all work with the same keyboard shortcuts. I use this several dozen times a day. As this obviously seems to be a contentious issue, it would be a bad idea to prescribe non-standard behavior - at least make it configurable. [1] https://bugs.kde.org/attachment.cgi?id=190307 [2] https://bugs.kde.org/attachment.cgi?id=190308 [3] https://bugsfiles.kde.org/attachment.cgi?id=190300 [4] https://bugs.kde.org/attachment.cgi?id=190310
Nobody deserves to be insulted in the bug tracker; not you, and not the people who are insulting you who you're fighting back against. It doesn't matter if you think you're the victim and other people are the aggressors; I guarantee the people you see as the aggressors here think the same about you. It's pointless noise that impedes people who want to get some actual work done. Stop it, *everyone.* I understand that this is an issue that gets people riled up, but please, *everyone*, keep your temper under control or else your account *will* be removed from Bugzilla.
(In reply to Nate Graham from comment #104) > It doesn't matter if you think you're the victim and other people are the aggressors; I don't *think* I'm the victim here, it's right there in black and white (that of it which wasn't deleted unjustly) and it goes back for *months*. I've actively taken steps away from this, I've been chased away from the forum, pinged here when I was minding my own business, and have been pursued into my personal email accounts and now verbally abused here and somehow I get the same treatment as they do? The only thing I can be accused of is calling those people trolls when they endlessly repeated the same bait, and it's pretty clear that I'm on the money. The only way I could have avoided it is to just be completely silent and have no say in the matter while trolls take over the show. > guarantee the people you see as the aggressors here think the same about you. Scrolling up here demonstrates otherwise. Not only have I supported from the very beginning that we really need something they can find intuitive (as in, I'm on their side for making it feel nice) I've only ever posted in here as a response to them. Meven explained enough on Discuss that I felt like he had a grasp on all the different facets of it (and I mean both sides of this discussion) and I was perfectly happy to sit and wait, and I did. Until I was pinged, to repeat the same arguments we've had before, impeding actual work (you're not the only one with better things to be doing). I pass it off as trolling because obviously firing up the exact same argument AGAIN is exactly that, and TraceyC supports the obvious trolling. Trying to lay the blame on me for the same handful of users repeatedly berating me in spite of my efforts to avoid them, is not gonna fly. I usually really like you Nate, but that's just rude. > It's pointless noise that impedes people who want to get some actual work done. Is exactly what I've been saying since OCTOBER. They won't freakin stop dude. The same exact repeated bait every time for MONTHS. I won't be threatened into accepting this abuse and I won't be victim-blamed over it because I refuse to take it lying down after nobody at KDE will do anything about it, and I won't be bullied into silence. Again, I'll invite you to discuss this with me in my personal email so that it doesn't trouble this bugzilla. My temper is doing just fine but I have a degree of self respect that demands better than this. If the cleanliness of this bugzilla and the resolution of this abuse is your goal, my email's right there. Or you could just victim blame me and threaten to delete my account. Honestly I thought you were better than that, Nate. I thought all of KDE was better than this. I'm not short of temper, I'm disappointed.
As original reporter I remove myself from CC caused by intolerable signal-to-noise ratio here.
Can you guys stop arguing here? I've gotten 22 emails about this thread in the past 12 hours, and it's just from the unnecessary bickering. Take your beef somewhere else, this is not what a bug tracker is for. I'm following this thread to get updates on whether or not this gets fixed, not updates on the status of your spitballing.
I would like to apologise for my previous comment which was unnecessarily inflammatory. I'm sorry to add to the noise, but I thought it was important to apologise publicly. I wish everyone a great day!
Git commit de4502909053fbea3295409540a97a5c74ca6611 by Akseli Lahtinen, on behalf of Geri Gelóczi. Committed on 05/03/2026 at 09:14. Pushed by akselmo into branch 'master'. Revert "!1026" The behavior change introduced in !1026 significantly alters the new folder creation behavior in Dolphin and has proven controversial among users. It likely requires additional design discussion and iteration to arrive at a solution that works well in all cases. Until a more robust solution is agreed upon, revert the change and restore the previous behavior. M +2 -16 src/dolphinmainwindow.cpp https://invent.kde.org/system/dolphin/-/commit/de4502909053fbea3295409540a97a5c74ca6611