Slightly strange behaviour in Dolphin

Help
141

Well, in list and icon view that would only really change the problem from “where did my folder go?” to “where did I go?” and just shows once more: all those workarounds keep on piling up, just to fix problems that got introduced by a “solution” that hasn’t even found which problem it’s trying to fix.

Sorry, but that is not what I asked. I don’t want to know the mechanics, I want to hear a use case. An actual reason why I would want to create a folder in a sub-folder that I’m not seeing the contents of. Because as things stand, this change happened because someone thought on a whim that it would be “more consistent” without giving a thought as to how it would improve usability.

Yes, but using the correct kind of consistency. Good UX is consistency in how the user expects the application to behave, not consistency in how the developers want to program their dialogs. And yes “things used to work this way for 30 years and every other application is doing it this way” is also a form of expected consistency.

Good on you for accepting that you don’t actually care if the user experience is good or not after all, but that’s not really helping. Because the “intention” is the important part.

142

the use case is the same one as the use case for using the context menu.

someone wants to create a folder in the folder they clicked on.

my expectation when using the context menu is that it will operate on the context of whatever i have clicked on (or whatever view i’m in).

choosing to use the keyboard to activate the same function rather than using the mouse means that keyboard users and mouse users both get the same UX.

i do care, or i wouldn’t be here explaining it to you.

what other indication of indention would you suggest developers act on?

143

Well, so far you are not doing a very good job of explaining. In fact, you’ve evaded my question a second time by going on about how “It’s the same use case as the context menu”, which it clearly even is not, because when clicking somewhere with the mouse there is a clear intent on where I click, while the “create folder” shortcut and toolbar button always had the connotation of “in current working directory” and changing it breaks learned user expectations.

So, back to my question, I take it you can’t come up with a reason why anyone would want to create a folder in a subfolder in icon or list view. Well, I don’t blame you because I can’t either. And still, you’re being very adamant about it somehow being better that way, even though it improves nothing while introducing new problems and unexpected behavior.

It’s okay if can’t change your opinion, it’s your application to develop and in the end I’ll have to live with the worse UX because I don’t have the knowledge or resources to maintain a fork, but let’s not act like this change was thought through to the end. At least admit that you built a “feature” that literally has no use other than to confuse your users.

144

Actually, I just came up with another suggestion to “keep the same behavior as the context menu”: just remove the whole “create new” section of the context menu when selecting a folder. Because, if we continue the thought, it’s utterly useless as well.
Again, it can work in details view if you expand the folders to show the created item, but why would anyone ever use this in list or icon view?

145

I’ve been thinking… :thinking: and it’s true that if I want to do something inside a directory in the icon view, I first enter the directory.

Doing Create new–>links options does make sense (I continue speaking of icon view).

Regards

146

Haha the issue is more nuanced really, isn’t it - about ‘intention’ and hypothetical issues and mental models… and ‘consistency’ is also confusing, because it might be a complete myth.

  1. ‘create new folder’ which creates a folder in the current spacial view. This is confused slightly by the list view, which isn’t quite a spacial view…
  2. Context counts, in icon view you can right click between icons, you can right click ON a specific element to act on that specific element, or you can use a taskbar button to act on the current spacial view, but then argue it should have acted on the currently selected element.

But we’re trying to think of an actual workflow, an actual reason behind these actions…

I have one… so I’ll tell you a story… imagine you just recovered a corrupt HDD, and have many media files… some .avi, .mp4, .flac and .opus files all mixed up in a /data folder.

Obviously we’re now in Dolphin in /data… and we’ll come across another ‘bug’ in Dolphin which doesn’t exist in Krusader…

Hit F3 to duplicate your pane, then you want folders… we want Audio and Video separated, and then we want 'AVI, MP4, FLAC and OPUS folders.

So in the new view, we can click ‘Create’ twice to create two folders (naming them each time - going from mouse to keyboard and back again, or using the keyboard shortcut)… or we can click ‘Create’ and type ‘Audio Video’ and create two named folders.

Note - using the keyboard shortcut is considered a niche, or ‘advanced user’ trick… whatever your opinion about it is… this is where more experienced users come a cropper discussing the issue. Such users, myself included, might be more inclined to want to type what they want.

So our view now, we are in /data. You can do this in the icon view b y carefully right clicking between icons and then going right to ‘+create new’ then right again to ‘Folder’ (which requires a fair level of skill) whereby you have a dialog - which is very nice. Type ‘Audio’ and choose your icon - we can choose another icon if we like. This is excellent.

Now you go back to the mouse, again try to accurately click on the background, not a folder, moving across ‘+create’ to hit ‘Folder’, then going back to selecting a folder icon and typing the name.

So having done this, I find the context clicking to be a little bit awkward - and we cannot type ‘Audio Video’ to create two folders, we will have a single folder named ‘Audio Video’ with a single icon and it’s not possible to create TWO folders with the single action…

Clicking an icon on the toolbar is a bit more efficient, but still singular in it’s action. This method is nice in that it prompts you to select an icon each time, though the ‘video’ folder required me to ‘Choose Other Icon…’ and then filter to get the Video icon.

Ok, so choosing folder images is a little niche - nice, but perhaps we’re already bored with this simple task. Why can’t we simply double click the ‘Create new folder’ icon to do the simple action ‘mkdir -pv Audio Video’… we must hit Enter each time to confirm, but that’s not a big deal is it? An extra action on the keyboard is more trivial for me personally.

This is where I get tripped up, in my spacial or List view now…

Create new folder ‘Audio’ (Enter to confirm) then Create new folder ‘Video’… we missed the issue now. I see only one Audio folder, but I do see a subtle sign that it now has a subfolder!

Ok, rewind… ‘Create new folder ‘Audio’’ followed by ‘Escape’ to deselect, then 'Create new folder ‘Video’.

We have completely skipped over the traditional method (not terminal) of doing this, we would press AltF for the File menu, →to go to the submenu to select ‘Folder’ with Enter.

This is very old UX, this is also very comfortable for older Windows users… and the menu items are all clearly labelled too and require no difficult mousing skills.

Then we have my personal choice, which is not for noobs and arguably not as accessible…

In our /data folder we can do F4 and type mkdir -pv Audio/FLAC Audio/mp3 Video/MKV Video/AVI

This works, because the terminal knows that a space separates items, and a slash creates subfolders…

The GUI also understands the slash will create sub-folders, but it doesn’t believe that spaces should create parallel folders.

So now the argument is a bit messed up, and context is indeed proving to be more important than consistency.

Screenshot_20251215_061942
Screenshot_20251215_061942580×305 31.8 KB

So now we go to our Android phone and find that we should actually do this another way… starting in /data again…

  1. Create folder Video’ and ENTER that folder.
  2. Create folder ‘MP4’, Create folder ‘AVI’.
  3. Back to parent folder.
  4. Create ‘Audio’ and ENTER
  5. Create ‘Flac’, Create ‘Opus’
  6. Back to parent folder.

No confusion, no trip-ups.

So for POWER users, you could possibly have a ‘New Multiple Folders’ function - in the right click, or shortcut, letting you type names separated by comma, or semicolon… or perhaps even a double-space would do the job.

147

apologies, i will try to be more clear in my words.

the use case is the user would intend to create a directory inside the selected folder.

i can only speculate as to why a user would want to do that, but a couple thoughts come to mind:

  • they plan to organize the contents of that folder by adding a sub folder where they can sort things into later
  • something they are working on in the current directory needs a sub folder to exist in that folder in order to function and it saves them from having to navigate to it and back before they can resume their work

i’m sure there are others that drove the creation of the Create New… context menu in the first place.

this is also true if you just right click somewhere in the current view (without selecting anything)… the result is the folder is created where you intended it by your selection.

like i explained earlier, the feature was already there.

a behavioral inconsistency existed between the keyboard shortcut and the context menu, and in the process of trying to reconcile that an emergent behavior was identified

because it turns out that matters what is selected each time you evoke the “create new” feature (whether by keyboard or by mouse).

if the selection is not changed by the process, then the emergent behavior is eliminated and the two ways of accessing feature become aligned.

and here i would also point out that your original default behavior of navigating to a folder to create the sub folder is also satisfied, so there is really no change to the status quo once the selection issue is corrected.

why do you want to take away someone else’s tool?

if i were going to change anything about the context menu i would simply remove the lising of keyboard shortcut Ctrl+Shift+N from being shown in the menu so no one would ever consider them to be the same feature (even tho they are).

148

I’m sorry, but your post is going all over the place and I can barely follow the narrative. I’ll just add that yes, I do disagree that using the keyboard shortcut for “create new folder” is a power user feature, for the simple reason that a toolbar button with the exact same functionality exists (which I use just as often) and “non power users” love clicking toolbar buttons. I don’t understand how you’re jumping from HDD crashes to multi-folder creation to android apps, but I feel it’s not productive to create huge complex cases while issue at hand is, at it’s core, rather simple: A workflow that existed for very long time (creating a new folder in the current directory) got changed to become more complicated (have be careful what folder is selected), with the change bringing no improvement (no use case for creating a folder out of view).

149

So, I’m not an expert on Dolphin history, but I’d wager “create folder in current working directory” has been there long before the context menu for folders was expanded to include the “create new” section. At least I’ve used this for a very long time, and actually if not for this thread, I would never even have had the idea to right click on a folder and see if a “create new” new option exists, because honestly, it’s ludicrous. So how is changing the “original” function the inconsistency?

Oh, sure, now I’m the one who “wants to take away someone else’s tool”, a tool you still haven’t come up with a proper way anyone would use effectively, other than “oh, but maybe they really want to, I don’t know, it’s not my problem if they shoot themselves in the foot with it”. Everything but having to admit the tool might be broken, because the developer is always right and it’s the users fault for using it wrong.

You’re trying to defend an incredibly niche workflow without an existing use case, while the established learned behavior of creating a folder in the current directory (which I stand by being the only place any user would ever want to do that) become prone to user error without any benefit, all in the name of false “consistency” the user won’t care about.

150

To be honest, “remove the context menu create option” was more of a joke suggestion at first, but the more I was thinking about it the more it dawned on me that there is not a single reason I would ever use it, because it brings with it all the same problems I’ve been arguing against in this thread. As you say, if I want to do something inside a directory, I enter it. Because then I can actually see what I’m doing, instead of blindly creating things.

I don’t quite understand this, though. “Create link” on a selected folder still creates the link inside that folder and I have to manually specify where to link to. If this was a “create link to this folder” option it might kind of make sense, though I still don’t think I’d use it that way instead of using Drag&Drop between views (panes, windows, tabs, …)

151

The whole problem here is how multiple folders are created.

The reason I came up with the scenario is that someone asked for it… specifically.

So many people will argue ‘this is how it SHOULD be, and I don’t like how it IS’ - yet when pressed, they cannot think of a single time that they actually DO what they’re complaining about.

The fact is that clicking on ‘Create new folder’ will do just that, in the current view - so what’s the issue here?

The issue is that it makes it awkward if you make more than one folder, the behaviour will be different (and not in an obvious way) if one folder is selected whilst generally that’s not how file managers work…

There is also a HUGE difference between using the keyboard or mouse - because the mouse has a spatial context… you could have one folder selected, but context click on ANOTHER folder. Tell me how that works with the keyboard?

Whilst the issue is presented as a ‘very simple issue’ it is actually not simple, it has many possible effects on users, and is genuinely more complicated than you’re trying to suggest.

You’re saying ‘no use case for creating a folder out of view’??? I was suggesting that this isn’t a good idea either, unless you context click a folder and select to ‘create a subfolder’. I think the word ‘subfolder’ must be used to create a folder out of view.

I don’t think this is satisified by having one function ‘Create New Folder’ which will behave differently in different contexts. This is a limitation we have here… I was comparing with some other file browsers, including my Android ones, and noticing that the context changes for every single case - there simply isn’t a fixed shortcut, or button, to ‘create new folder’ in different contexts - the whole application adjusts to present options clearly.

That’s what’s missing here… and if it can’t be actually improved, best leave it broken… because the one thing people complain about most, it’s not the lack of improvements…

They complain most about changes - and that includes many good changes. I don’t think any UI change in history was ever introduced without millions of people blowing steam out of their ears.

152

the original keyboard shortcut function should not change for the use case you have outlined.

if you enter a directory and hit Ctrl+Shift+N you will be prompted to create a new directory in the folder you just entered.

this is entirely consistent with how that shortcut has worked since forever.

the only question to be resolved is what happens next.

the change that everyone is talking about here unintentionally resulted in the new folder being selected.

that changed the “original” behavior so that if you hit Ctrl+Shift+N a second time then it would create a folder within the folder you just created instead of creating a folder along side it as expected.

the solution is to NOT select the newly crated folder and then the behavior returns to the “original” form and nothing has changed from the perspective of your use case.

1 Like
153

@ben2talk thanks for explaining again, I think I get it now.

I guess we do complain about similar issues, even if from different angles. My problem is with the change in creating new folders in the first place, of course this also extends to creating multiple folders somewhere down the line. I don’t usually complain about changes in general, but if they lessen the experience while not providing any improvements it’s a hard pill to swallow. And to be honest, dolphin is one of my favorite applications and the main reason completely switching from Windows was so easy and empowering, so I really want it to stay great.

154

But it did change, and that has been my argument from the start. folders get selected, either by me, or by some automatic action, and I as a human can not be expected to memorize and follow the complete application state, I don’t always actively know which folder is currently selected when going about my tasks, so I will accidentally create folders in a subfolder with the current implementation. It’s been happening for weeks. Also, selecting folders itself is not a bad thing, as you keep implying. When creating a folder, it is the most natural thing for it to become selected, because I probably want to keep working with it, by navigating inside and creating files in some manner, so

I don’t see this as solution. To me, this is just another workaround which will end up breaking even more workflows, as specified above, all in the name of justifying a change that was not needed in the first place.
And again, no one has answered my actual points on the negative aspects this change has on the user experience in general, you just keep avoiding them, I feel we’re running in circles and it’s quite frustrating, actually.

Mostly you, actually. There were quite a few replies earlier in the thread’s life that complained about the change in general and I was picking up the discussion from there.

155

now does not automatically selecting the folder after creation break your workflow?

what is the use case for this automatic selection?

the only way to satisfy both methods is to keep them separate so that the shortcut would create only ever in the current view and automatically select the folder when it exits.

while the context menu would create a folder in whatever was selected (or the current view if nothing is selected) and NOT automatically select the folder…. in which case Ctrl+Shift+N should be removed from the context menu because they are no longer the same function.

but i see this as a workaround rather than trying to unify the UX.

156

I described the exact use case in the post you’re quoting. After creating a folder, most of the time I want to navigate inside and extract an archive into it or copy files over, so I create a new folder in the current view using the toolbar button (or the shortcut, if you insist), and then press enter, because my hands are already on the keyboard from typing the folder name. What else am I going to do with a newly created folder? Any action I can think of includes selection of the created folder, just as you’d select a file after creating one to open and edit it.

I don’t see why this should suddenly be an unsolvable problem either, when dolphin has literally worked this way for years, probably decades at this point. The only reason it even became a debate is because of the recent change, which, again, improved nothing and brought a whole slew of issues no one has a clear answer to so far.

So here is my real solution: just roll it back. It already got rolled back once, for good reason, and I don’t understand why it came back, because nothing was noticeably changed from the first version that got rejected.

157

as i have explained to you, the reason for the change was to reconcile the different behaviors between the shortcut and the context menu (which you apparently don’t use, so haven’t noticed).

it’s true that the differences could be left in place and no changes made…. let the users sort it out.

that’s always an option for any software.

158

I tried to make directories and no one gone inside of another (icon view). Process:

  1. Ctrl+Shift+N
  2. Ctrl+Shift+N
  3. Right Click–>Make new folder
  4. Ctrl+Shift+N

image
image1858×953 31 KB

Seems selected but the folder is made in PWD, as always.

Regards

159

right click on what?

folder or background?

what version is this?

160

Background. In folder makes a subfolder.

Regards