i would like this too but how would expect that to work with icon and detail views?
there is not “expand” option in those views, there is only changing the PWD which would seem like over reach when the user only wanted to create a folder, not change directories.
perhaps i should clarify:
when i write PWD i mean the directory listed in the path at the top of dolphin, or if you have a terminal view open the path shown when you type echo $PWD
if you are in test and you create a folder 1, your PWD is still test even tho 1 is both focused and selected.
That would be more reasonable. But that’s not what you asked for:
And I honestly don’t think you quite understand what “this whole nested thing” is, so I took the time to explain it, since it’s implied if you use it, but it hasn’t been explained here yet. Now it has.
No that’s why we’re thinking of something better.
Your definition of “I am here” is flawed, that’s what’s wrong with it. It’s not consistent with dolphin’s capability. “Here” can mean a lot more than you seem to expect. It’s not a folder, it’s a structure of folders, it’s a whole subtree.
The most “here” part of it is the part that you selected. And that might be 10 folders deep from the one in the address bar up the top. And it’s always been that way. Just that before, the new folder wasn’t automatically selected for you after creation. There was a bug. It’s fixed now, and it has uncovered this problem. Putting the bug back is obviously not smart, and deleting the 99.99% perfect thing for the 0.01% problem we just found is no better. So we need to figure out what to do next.
You seem confused. It absolutely should.
This is how selecting objects and performing actions on them works literally everywhere, including elsewhere in dolphin. You’re just confused about what’s selected, because you’re accustomed to the file manager selecting the current location (the thing in the address bar at the top) as the current working directory (the place you’re going to perform actions in), because in the other file managers it’s the only directory which possibly could be. So you think that the actions you perform occur on the current directory. They don’t, they occur on the selected object. Here in dolphin and in windows explorer alike. Dolphin does not have that limitation, but you bring the limitation conceptually. It’s not appropriate.
meven has specifically said it would be bad 
Like I said. Expand it.
Yeh those options sucked, there weren’t enough to start with and you knew half of them didn’t work when you typed them 
Like I said:
That works and nobody has replied about it and also nobody has said why there are only 2 options. You just repeated the problems to me that I just offered the solution to.
Like I said before, what about if we’re not creating child subfolders? What if we want it selected to create a file in it and open it in kate? Or open that new subfolder in a terminal? Or open the embedded terminal in dolphin at that location?
Selecting the newly created directory makes sense. Performing actions on the selected object makes sense.
Not selecting the newly created directory makes it hard to manually select. Not selecting the previous working directory, is easy to manually select. The only real problem with it right now is that it doesn’t make the working directory’s contents visible when you act on it.
You guys seem to be arguing this because of something we all agree on: the sibling folder creation feels intuitive. But maybe, just maybe, there are a ton of other stuff you can do after you create a folder, and just one of them is create another folder, and of the ways to do that, just one of them are sibling folders… maybe it’s not worthy of as much weight as it’s being given. Maybe the problem is our intuition?
This is a problem, it feels unintuitive, no argument from me there. But some of the solutions being suggested aren’t productive at all. All the facts and logic are going out the window to try and support arguments that this one rare use-case should delete everything else. We get it. You use that use case. So do I. That’s why I’m here.
Difference is I’m being real about it and recognising it might just be a me problem that it didn’t work how I thought, not a problem with how it works… Or at least, that the answer is not that it should behave exactly as I expected, but that maybe we can find some way we didn’t expect, that will get the best results for everyone.
Wearing blinkers about how to fix this is not productive at all and scrolling up demonstrates it. There are not only two possible solutions and dolphin should not act like explorer, especially if it cripples dolphin, for the express purpose of not breaking familiarity with windows explorer. There’s sanity in the current behaviour, even if we don’t like it. We need to find something that retains that sanity but also feels intuitive; not blindly deny that sanity because it felt unintuitive the first time we ever tried it.
I experienced the problem, went “what the heck?”, searched for bugs, read the reports, read the explanation from the devs, and went “Oh. That actually makes sense. That was pilot error. Dang it sucked tho”. I don’t know why a few of you are having trouble getting on that wavelength.
Yes it is hard to know the users expectations, and polling while appealing would be unreliable.
The current polling system we do have : release code, get feedback. 
This change was asked by some user initially .
i’m with you that a user will likely want to work with the newly created folder… otherwise why create it, right?
so this is option 2 from my previous post where the newly created folder is selected.
the problem i can see with that is the behavior (and hence the solution) need to be different depending on if the user is in details view vs one of the others.
in details, it should be straightforward enough to simply expand the tree to show the newly created folder and then mark it as selected (i’m not a developer, so i could be talking out my ass here).
but in compact or icon view that option doesn’t work… so what now?
option 2A) switch the dolphin PWD (the path at the top of dolphin) to the newly created folder…
option 2B) leave the selection at the parent folder and create the new folder as nested within
i would prefer 2A, but would not want this solution applied to the details view in which means there would need to be two separate ways to handle new folder creation.
edit: now that i think of it there is another possibility
option 2C) only offer the ability to create a new folder in PWD
don’t know if this would be messier or not.
If only 1 or less than 10 users (in the bug) claims for this feature, is not better remains as before (working always in PWD) and make it optional the other behaviour? (in settings or some other form)
Maybe… first make a folder called 0 with Ctrl + Shift + N. And if you click again Ctrl + Shift + N :
You enter 1 to call the new folder and click in the checkbox for tell Dolphin that the folder 1 goes into the folder in focus (or selected). I hope it is understandable my proposal.
I saw that you can choose icon and color. This checkbox would be and option more.
Regards
Yeh good post agree all through. I like 2A but I don’t use that mode, so I’m not a good judge. It’d work, though.
‘Overriding the selection’ like 2C seems like it would please most people. The downside is that people who really did want to make a subfolder they can’t see and didn’t want to do anything with it (seems imaginary but OK), would see it appear in the PWD rather than the thing they clicked on… But at least it would be obvious what happened.
I guess that’s the tradeoff between 2A and 2C: One is potentially jarring, one is behaviourally inconsistent… In some strange edge case. Honestly I like your 2C better. Also it’s the “pls delete nested folders” manifested, but only when people aren’t using them. Seems almost perfect.
It would be good to hear whether any of this is feasible from someone who knows the code. Still, great idea @skyfishgoo
i think 2C is better as well, it’s basically the pre change behavior but only for icon and compact views.
no idea how much code would would be required to segregate them from detail and then fix details to expand out the new folder in the tree.
might be easier to just roll back the change for all of it and be done.
Very disappointing turn of events.
I thought we were supposed to talk about stuff on discuss so the bugzilla didn’t get cluttered with threads like this, but by doing so I’ve excluded myself from the conversation that would be heard.
i think it was just easier, and it wouldn’t have mattered.
It does feel like “this turned out to be a monster and I wish I never touched this code. Revert, Eject”
That’s good. I can imagine trying to improve something, putting in a month or two of work, getting it through… only to discover some unpleasant side effects.
So should I be narcissistic and keep it in place, trying to butcher it into working? Or should I revert to the previous state (with which most folks didn’t have any issue) and think again before pushing it through?
I know what I’d choose:
Roll back and think again FTW
I hope that happens, because a lot of us do have issue with the old behaviour. It is a real a11y problem when your mouse and keyboard argue about whether you have selected an object or not. I know you’re not a fan of the mouse personally, but some of us lack choice in the matter.
This was always complex because it was one problem up against another, so let’s not diminish the real problem that existed before it was solved and led us to this one.
Likewise let’s not imply that I took any exception when I made the above statement. You don’t need to start out with “that’s good” because I never suggested it was or it wasn’t. It was just an observation.
For the record, I don’t take any issue with ‘revert, eject’ and leaving it as it was until another solution comes along. I do take issue leaving it as it is forever and with marking it as intentional, though.
Agreed, and I very much doubt that’s what is happening.
That’s what it says in the MR
This will reintroduce https://bugs.kde.org/show_bug.cgi?id=508196 but it will get marked INTENTIONAL.
I got it, from the BUG: 508196, there are a bunch of users needing this, we have a clear contradiction.
The solution I am thinking is having two distinct actions: from shortcuts (create in view directory) or from context menu (create within selected folder). MR 1088
But it has its drawbacks. The shortcuts isn’t the same as the context menu, still.
FYI, I am the developer behind the decisions and this got my attention to say the least.
This does not give any guarantee (I am a benevolent developer) still.
My question is still, what it the best behavior to adopt to satisfy the classic shortcut expectations, and the keyboard-navigating/context menu users ?
An option could be the last recourse, but we don’t want half the users to have to go to the settings just to change this, this isn’t a good outcome.
the UX should be the same for both the shortcut and the context menu.
the problem now becomes a GUI problem of how to manage the display and/or selection of this new folder…
the short answer is to not display or select this new folder and leave the selection where it was before the shortcut or context menu was activated.
the user would then have to manually navigate to the new folder on their own and select it if they wanted to do further work with it (create a nested folder/ document / whatever).
by not selecting the newly created folder (or even showing it) , the view dependent handling of how to display the selected folder is avoided and no automated navigation or view manipulation is required.
this would answer the bug report without introducing new issues
and it preserves the discoverability feature of using 1/2/3/4/5/6 in the dialog box to create nested folders without complicating or affecting the GUI.
Today I see all normal. If I do, without any selected:
Makes a folder 1, with 2 inside 1, with 3 inside 2 and with 4 inside 3. Works in Icon, Compact and Detail views.
~/Descargas tree 1 ✔ 23:04:11
1
└── 2
└── 3
└── 4
4 directories, 0 files
If you want make the same but inside of an axisting folder, you only need select the folder. Works in Icon, Compact and Detail views too.
Regards
Edit: Sorry this was meant to reply to @meven but something went wrong
Yeh, I got the impression that you saw both sides of this. It’s a tough one mate, that is for sure. We all appreciate the significant effort you’ve gone to for us all.
This is a pretty big drawback for me. I very frequently swap from keyboard to mouse. Like, I might rightclick it and then use the keyboard to select the menu options; or use the arrow keys to select it and then click the button in my toolbar. I swap devices all the time, even mid-action. I did it twice in that sentence.
It’s because I have bad hands, so how I do it every time will mostly depend on what I did before it, if my hands are near those keys/on the mouse, if that hand needs a rest, etc. Though I do it because of my hands, I think that most users who are concerned about ‘consistency’ it is for the same reasons of efficient movement (and some input scripting stuff but I’m trying to keep this short haha).
I think probably the best thing, at least temporarily so that a developer can leave it indefinitely without bugs; to give consistency, and to give an intuitive behaviour, and to keep the solution simpler to implement; would be to create the folder in the selected folder (fallback to view directory if no folder selection), and then select the parent (not the new folder).
It leaves some smaller problems like navigation to the new folder, but it takes care of the big problems the easy way. For a more ‘complete’ solution in the future I really like @skyfishgoo’s 2C idea.
Thanks mate.
