Creating a new tab currently duplicates the tab and switches to the duplicate. Since they are duplicates, this behavior doesn’t really matter. However, when opening a folder in a new tab, the tab is created without being switched to. This makes the workflow inconsistent, and a bit more difficult to do the standard workflow example of Copy file > open folder in new tab > paste in folder tab > close tab > copy different file from original folder.
The point of opening without focus, is that it can be more appropriate:
- you might not be in the folder where you want to move files from
- you might have not done you file copy yet
- you can use make use of drag-n’ drop instead of the clipboard this way
And switching to the other tab there a shortcut “Ctrl + Tab”.
What we might do is allow to switch to a open in new activated tab when shift is held.
Similarly to delete / shift delete.
What do you think ?
I’ve also always found this behavior for “Open in New Tab” a bit odd, because (1) probably in most cases what the user expects is to open the specified folder and show its contents, except they have selected more than one folder, of course, and (2) it is also inconsistent with the behavior for “Open in New Window” as well as “New Tab” and “Detach Tab”.
So, IMHO, selected folder should be opened in a new tab without focus only when Shift is held (or when more than one folder is selected, of course), not the other way round.
An unnecessary step if you add an option in settings for this and a option in settings for clicking an item in Places to open in new tab instead of having to rightclick and select.
Something I forgot, middle click + shift open a tab in the foreground already, and middle click in the background.
Maybe you just needed to learn about that middle click feature.
We’d need to invert the shift meaning there too.
Dolphin has too many features to keep in mind! ![]()
But I still think, for the sake of consistency, it might be better to open the selected folder in a new tab in the foreground via right-click > “Open in New Tab”, although it’s not a big deal since we already have that shift+middle-click shortcut for that. ![]()
Dolphin is meant to be a feature treasure trove available to those that looks for them or dares the adventure, while keeping this as-discreet-as-possible and discoverable.
Middle-click actions are the least discoverable sadly. That’s a KDE pattern to make use of the middle click beyond scrolling and tabs management. In the plasma systray for instance to mute sound or microphone, turn-off wifi or bluetooth. I personally love those features.
So I did a MR for this dolphinmainwindow: switch to the new tab a context menu opens (!1392) · Merge requests · System / Dolphin · GitLab and kio Open a new tab active, and in the background with Shift (!2378) · Merge requests · Frameworks / KIO · GitLab
This changes a lot of things to accommodate the new default behavior.
yes, it would be a welcome addition if the shift key changed the context menu to show that it will switch to the new tab, similar to how the delete operation is modified
context menu (without shift held):
context menu (WITH shift held)![]()
—
but it would also be necessary to modify the behavior of this context menu from the places panel, so that there is consistency, and i don’t know how easy that would be.
context menu (without shift held):
context menu (WITH shift held)![]()
—
wondering at this point if it would not be easier to provide a global option in the configuration menu for the behavior of opening a new tab
that’s what i was trying to remember !
My MRs do that ![]()
That’s why I add to do a kio MR, that’s where most of the Places panel is implemented.
Quoting the mr description:
Nothing told the user about the Shift key, so the entries which open a tab now carry a tooltip
saying what it does, and their text becomes “Open in New Background Tab” while Shift is held down.
I’ve sincerely never had a proposal of mine discussed to such a great length as this! I think adding a global check box is a good solution, on by default. Whatever the solution ends up being, I look forward to its rolling release (Go Solus!) and express my enduring gratitude to the KDE community!
BTW, I realized that Windows File Explorer actually has the same behavior. However, I still enjoy the discussion around this proposal!
Got tired of reading through this after a while, so forgive me if this has already been pointed out by someone else.
Firefox and Brave (and web browsers in general, I imagine) work the same as Dolphin currently does - i.e. right-click → Open in new tab = Open in background tab. It works the same when I middle-click a folder or middle-click a web link.
And when I duplicate a tab in Firefox or Brave, it immediately switches to the duplicate. So, I’m not sure what inconsistency there is because this seems to be the common functionality for tab-based browsing/exploring.
That said: Having a way to switch it to what is preferred by a user would be good.
Great datapoints, I understand now why we had this behavior.
Browsers are more ubiquitous than windows explorer, so setting the expectations based on them seems like a better approach.
So we might want to do the opposite: open in the foreground with SHIFT to match browsers.
Again, I’d like to avoid a setting, I don’t think that’s necessary here. There is a limit to the extent an application can support. And here that would be very complicated…
A setting is only necessary if a whole workflow is very hurt by not having it. Here I’d rather have an explicit and simple escape hatch.
I like this proposal! It’s so simple and straightforward. It addresses the fact that while the default behavior was in fact consistent, it gives a single key action to produce the intended speedy flow enhancement!
Just chipping in that “open in background” seems to be the default on Nemo, as it seems to be in browsers, although have only just discovered that as by habit I use new windows rather than tabs with a file explorer.
A modifier key to alter that behaviour that seems the best fit.
I think Shift would be the ideal modifier for the “switch to the new tab immediately” behaviour (Ctrl + Shift + primary click / Shift + middle click). This behaviour is already present in basically all web browsers (or atleast Chromium, Firefox and Zen Browser).




