Bug 453700 - dolphin in detailed view open files and folders also if I click elsewhere on the line not only on the filename
Summary: dolphin in detailed view open files and folders also if I click elsewhere on ...
Status: REOPENED
Alias: None
Product: dolphin
Classification: Unclassified
Component: general (show other bugs)
Version: 22.04.1
Platform: openSUSE RPMs Linux
: NOR normal with 101 votes (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
: 453198 453528 455110 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-05-12 13:29 UTC by pier andre
Modified: 2022-08-03 07:22 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pier andre 2022-05-12 13:29:06 UTC
dolphin in detailed view open files and folders also if I click elsewhere on the line, size, date etc., not only on the filename as it was in version 20.04.2.
this actual (version 22.04.1) is very annoyng and should be repaired as soon as possible

STEPS TO REPRODUCE
1. set preferences to open files with one click
2. set dolphin in deailed view
3. click everywhere on the line after the icons, not before the icon and not on the filename or on the icon

OBSERVED RESULT
the file or the folder in the line is opened

EXPECTED RESULT
the file or the folder in the line isn't opened neither selected, nothing happen

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
discussion on:
https://forums.opensuse.org/showthread.php/569581-dolphin-in-detailed-view-open-files-also-if-click-is-on-the-row-and-not-only-on-the-filename
https://forums.opensuse.org/showthread.php/569710-New-ultra-annoyance-Dolphin-Drag-and-drop-broken
https://forums.opensuse.org/showthread.php/569710-New-ultra-annoyance-Dolphin-Drag-and-drop-broken
Comment 1 Nate Graham 2022-05-12 15:22:57 UTC
This is the intentional new approach in Dolphin. It was done to implement a very long-standing request: Bug 181437.

I know it's a change, but I think you might like it if you give it a chance.
Comment 2 pier andre 2022-05-13 11:31:27 UTC
(In reply to Nate Graham from comment #1)
> This is the intentional new approach in Dolphin. It was done to implement a
> very long-standing request: Bug 181437.
> 
> I know it's a change, but I think you might like it if you give it a chance.

I gave a chance for about one month, I didnt noticed that it was changed until I made a lot of errors clicking on files and dropping files in wrong places and cannot have the correct right click menu', it's an annoying behaviour becouse you have to give too much attention to where you click and drop and it is too easy to open a file unintentionally by clicking somewhere to the right of the file name.
and also when you drag a file you drop it in the row and it goes in the activated folder instead ov in the folder and also when you rightclick the menu depends if the row is activated or not, I really prefere that this behaviour be an option as KDE traditional approach and not to have no choice
Comment 3 Nate Graham 2022-05-13 12:48:35 UTC
*** Bug 453528 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2022-05-13 13:59:13 UTC
I will agree that drag-and-drop is regressed because it's now much harder to drop into the view, rather than a folder within it. That seems like a legitimate issue we can improve upon.

Can you please open a new bug report about just that, and we can look into it. Thanks!
Comment 5 Richard Ullger 2022-05-20 22:27:20 UTC
The change that is causing these issues is in my opinion a bad design decision.

I can no longer copy or cut a file and paste it using the context menu unless the dolphin window contains empty space below the last file/directory. Where the window is filled with a list of files or directories, the context menu when clicked on a line that contains a file does not contain an option to paste the file. When clicked on a line that contains a directory the option to paste is there but the file is pasted into the directory on the clicked line instead of the directory being viewed.

I can no longer drag and drop a file into an empty space in a dolphin window that is filled with a list of directories. The file will be dropped into the directory of the line where the mouse button is released instead of into the directory being viewed. I have misplaced files several times because of this until I realised what was happening.

I can no longer click on an empty space after a file name to deselect a file. Doing so opens the file or enters the directory. More attention needs to be paid to click to the left of the file or directory name to deselect it.

I can no longer click on the empty space after a file or directory name to select the left or right pane when in split view. Doing so opens the file or enters the directory on the line clicked.

All these in my opinion being regressions from previous versions making dolphin annoying and more difficult to use.
Comment 6 Jérôme Borme 2022-05-21 16:15:15 UTC
I found you can click on the empty space right of the file name and drag a few pixels, it creates a selection rectangle and it will select that file (sure it requires some additional effort). You can also keep CTRL keyboard key before clicking on the file (not required when dragging to select several files).

I think one great opportunity here to improve the selection mechanism of dolphin would be, while keeping the full line highlight introduced recently, to let only a click on the Name column to trigger the Open action, while the optional columns of the Detail view (such as: size, timestamp) would act only for selection.
Comment 7 Nate Graham 2022-05-23 15:05:59 UTC
That's exactly how it was before. :) And it was unpopular.

Of course, this seems to be unpopular too, among a different group of people. Sometimes you can't win. UX design is hard.
Comment 8 Jérôme Borme 2022-05-23 18:17:25 UTC
If you agree there are two groups of people that cannot be simultaneously pleased, would that be enough justify making it a configurable feature?

It seems user group complaining right now are single-click users. Since single-click is supported by Plasma, it makes sense for the applications to offer appropriate options when relevant.
Comment 9 Nate Graham 2022-05-23 19:30:17 UTC
That's the nuclear option. I'd prefer if we did some more UI design work first to find something that works out-of-the-box for both groups automatically. Only if that fails would it make sense to add a user-configurable option IMO.

Maybe this whole feature itself should be automatically turned on or off based on whether you're using single-click or double-click.
Comment 10 Felix Ernst 2022-05-24 13:17:35 UTC
>I can no longer copy or cut a file and paste it using the context menu
>unless the dolphin window contains empty space below the last file/directory.
>Where the window is filled with a list of files or directories, the context menu
>when clicked on a line that contains a file does not contain an option to paste
>the file. When clicked on a line that contains a directory the option to paste is
>there but the file is pasted into the directory on the clicked line instead of the
>directory being viewed.

This part is not a design decision but a bug. I opened a merge request that should fix this: https://invent.kde.org/system/dolphin/-/merge_requests/399 – Thanks for letting us know.

--------------------------

I agree with most of what Nate said. Drag and Drop might be something we should change so dropping on top of an empty row drops the item on the view area and only dropping on top of a folder icon or name would drop inside the folder. This could be made clear by clearly highlighting the folder that receives the files.

I am also not sure yet if having a setting for this is the right decision. I am not aware of a downside that seems exclusive to single-click mode but it is of course true that clicking a row used to deselect items and now counts as a click on the item which should be similarly unexpected for single-click users and double-click users (but the result is worse for single-click users). I am testing the potential regressions myself currently by exclusively using Details view mode in single-click mode and even hiding all extra side padding.

This certainly leads to slightly different usage patterns because I can hardly use the side padding for drag and drop or deselecting. The most prominent change in behaviour for me is that I don't bother clearing the selection anymore if only one item is selected. There is also no reason for me to ever clear the selection other than a feeling that one doesn't want a file to be selected.

>I found you can click on the empty space right of the file name and drag a few pixels,
>it creates a selection rectangle and it will select that file (sure it requires some additional effort).

This was also the old way of selecting singular files in single-click mode so this hasn't changed.

> You can also keep CTRL keyboard key before clicking on the file
>(not required when dragging to select several files).

One used to need to Ctrl+click the file's icon or text to select it. Now Ctrl+clicking the same row works.
Comment 11 basjetimmer 2022-05-24 13:21:13 UTC
I also strongly dislike the new behavior. Apart from annoying me like I didn't know was even possible, it makes some things a lot more difficult. The first thing that comes to mind is trying to move something (drag-n-drop) into the root of a directory with only subfolders in view, which is damn-near (or maybe even literally?) impossible. Getting the desired right-click context menu as mentioned above as well.

Also, I tend to want to actually _deselect_ things, which is admittedly non-functional, but very much harder to pull of now.

The old behavior was considered unpopular (apparently) based on the existence of a feature request. Well, this behavior is also unpopular as evidenced by this bug report (as well as comments on Bug 453528 and Bug 453528). Who's to say which is more unpopular, have things improved or worsened? A revert would cause Bug 181437 to be reopened (though I personally wouldn't mind). This so obviously just needs an option in the settings.
Comment 12 Felix Ernst 2022-05-24 15:01:44 UTC
>Drag and Drop might be something we should change so dropping on top
>of an empty row drops the item on the view area and only dropping on top
>of a folder icon or name would drop inside the folder. This could be made
>clear by clearly highlighting the folder that receives the files.

https://invent.kde.org/system/dolphin/-/merge_requests/401
Comment 13 thwrnr0 2022-05-25 22:32:22 UTC
*** Bug 453198 has been marked as a duplicate of this bug. ***
Comment 14 Johannes Schmidt 2022-05-26 10:15:40 UTC
The biggest issue is that it's very unintuitive to have no empty space in the view that doesn't cause an action on drop or click.

For example, I used to click into the empty space to select the view (in split mode) for toolbar commands or to sync the terminal directory. Now, after some adjustment period I found that I can click the scroll bar if the directory list is full.

Similarly drag&drop works same as before by dropping on the column headers instead of directly into the pane. It works and I'm starting to get used to it, but it sure as hell isn't intuitive. It took me a few seconds of trial and error to find some surface I can use to get my file where it should.

Adding to the unintuitiveness of these weird usage patterns that this behavior encourages, there is also the inconsistency. For example, when clicking to the left of a file, an unfolded directory tree, or exactly between the arrows, that space still seems to have the old behavior where a click doesn't select the line. I've caught myself a few times unfolding a directory just to have a reliable space to click into.

So while I would much prefer the old behavior back, I would also happily settle for a consistent, less unintuitive compromise.
Comment 15 thwrnr0 2022-06-12 18:14:43 UTC
*** Bug 455110 has been marked as a duplicate of this bug. ***
Comment 16 Felix Ernst 2022-06-16 09:11:41 UTC
Git commit 5ebf2065d525160a29f1d7aeef41541c6033bccf by Felix Ernst.
Committed on 16/06/2022 at 09:11.
Pushed by felixernst into branch 'master'.

Don't consider drops on a row as drops on the row's item

Since d3839617193e92463806580699caa595c892b8a6 in details view mode
clicking anywhere within the row is considered a click on the item.
That commit also changed it so that dropping files anywhere inside
a row would make it so the files are received by the folder of that
row.

This commit reverts the drop behaviour to be identical to the old
one.

I am having trouble explaining why this is better because one can
look at it in different ways. Bottom line is that one doesn't
really feel like one is dropping files inside a folder unless the
mouse cursor is actually directly above a folder's icon or name.

Another argument is that it is normal behaviour to just throw files
onto an application and the files then being opened by it.
Having potentially large parts of the view area covered by the rows
of folders means that there has to be more of a conscious effort to
not drop the files inside one of the folders by accident while with
this commit one has to aim precisely onto a folder to do it
intentionally.

M  +22   -2    src/kitemviews/kitemlistcontroller.cpp
M  +9    -0    src/kitemviews/kitemlistcontroller.h

https://invent.kde.org/system/dolphin/commit/5ebf2065d525160a29f1d7aeef41541c6033bccf
Comment 17 Christian Hartmann 2022-06-18 07:29:45 UTC
being a single klicker for years, i'm not a big fan of the new "use the full row" behavior.
and actualy switched to double clicking experimental wise. said that...

using the full row as a drop zone at least is/was consistent! now this feels weird IMHO.

as other posters mentioned above, it is practically impossible to deselect any item with
a dolphin window totally crowded with items, and there no space left, that belongs to the
current displayed folder. if single clicking or double, no difference.

what about de-selecting items with a second (not double) click on an item?
Comment 18 Martin Koller 2022-06-18 21:46:49 UTC
In addition, this "whole row selection" now makes tooltips of files very annoying.
I just want to see the details (in a tooltip) when I actually point at a file (name, that is).
Now it's impossible to NOT point at something.
Comment 19 Dušan Dragić 2022-06-19 13:43:25 UTC
Just throwing in my vote for a configuration option for this. I tried to get used to this new behaviour, but it's still annoying me and I'm a double-click user.

(In reply to Johannes Schmidt from comment #14)
> Adding to the unintuitiveness of these weird usage patterns that this
> behavior encourages, there is also the inconsistency. For example, when
> clicking to the left of a file, an unfolded directory tree, or exactly
> between the arrows, that space still seems to have the old behavior where a
> click doesn't select the line. I've caught myself a few times unfolding a
> directory just to have a reliable space to click into.
> 
Yea, I went one step further and enabled "Leading Column Padding" so there is always empty space on the left to click on...
Comment 20 Felix Ernst 2022-06-20 10:34:00 UTC
(In reply to Martin Koller from comment #18)
> In addition, this "whole row selection" now makes tooltips of files very
> annoying.
> I just want to see the details (in a tooltip) when I actually point at a
> file (name, that is).
> Now it's impossible to NOT point at something.

Please file a separate bug report for this. This is something we will want to fix no matter if there is going to be a configuration option for this or not.

(In reply to Dušan Dragić from comment #19)
> Just throwing in my vote for a configuration option for this. I tried to get
> used to this new behaviour, but it's still annoying me and I'm a
> double-click user.
> 
> […]
> Yea, I went one step further and enabled "Leading Column Padding" so there
> is always empty space on the left to click on...

We are still considering whether to add a configuration option for this or not. First of all I want to discourage people here to all write "I want a configuration option too!". Since Dolphin has many millions of users we can't base decisions solely on the quantity of feedback we get by advanced users able to find this bug tracker. Feedback saying what exactly doesn't work anymore for you would be better e.g. "I have trouble selecting files under <these circumstances>".

Unfortunately there were some usability bugs with the new behaviour and now we have some feedback of people wanting to opt out of all of the new behaviour and we can't be sure if that is mainly because of bugs that can be or were already fixed. (We also have feedback of people being happy with the new behaviour.)  For example the "Leading Column Padding" should have been enabled by default so there is always an area to deselect/click the background.

That being said, there shouldn't even be much of a need to use the padding area to click the background. As can be seen by my comments above, two bugs were already fixed that now allow a bigger drop area for files and a bug to right-clicking was also fixed. One reason to click the background/view area that seemed valid to me at first was for people using split view wanting to switch the active view. But then I couldn't find a reason to do that without also selecting a file because mouse navigation works normally without activating the view first.

So it seems to me like we need to unfortunately take a more long term approach towards deciding this. We'll monitor the feedback after 22.08 is released and then we'll see if there is a way to decide objectively if there is enough reason to take on the maintenance burden of having this as a configuration option. I am sorry if this isn't the immediate feedback some of you were hoping for.
Comment 21 Martin Koller 2022-06-20 10:45:53 UTC
(In reply to Felix Ernst from comment #20)
> (In reply to Martin Koller from comment #18)
> > In addition, this "whole row selection" now makes tooltips of files very
> > annoying.
> > I just want to see the details (in a tooltip) when I actually point at a
> > file (name, that is).
> > Now it's impossible to NOT point at something.
> 
> Please file a separate bug report for this. This is something we will want
> to fix no matter if there is going to be a configuration option for this or
> not.

Done. Bug #455645
Comment 22 Philipp Maierhöfer 2022-06-21 19:49:34 UTC
The new behaviour caused a lot of frustration to me as a single clicker. But I'd like to suggest a compromise that avoids a configuration option and hopefully both sides can agree on. Let's start with some reasoning.

In my opintion, a clickable area should either uniquely belong to an item in the folder, or to the folder that contains the item.
* "belong to the item" means left click opens it, right click opens its context menu, dropping something on it means into it, click and hold drags the item, and hover opens the item's tooltip.
* "belong to the folder" means left click unselects selected items, right click opens the context menu, dropping means into this folder, and click and hold activates the rubber band selection.

Now we have an odd mixture: the entire row belongs to a list item if you click on it, but (apart from the name) it belongs to the folder if you use the rubber band, open the context menu or (with https://invent.kde.org/system/dolphin/-/merge_requests/401) if you drop something on it. This seems quite counterintuitive to me.

So here's my suggestion: Treat the space within the "Name" column as if it belongs to the item with all consequences (see above), but the space within all other columns (Size/Modified/Owner/...) as if it belongs to the folder.
Comment 23 Nate Graham 2022-06-21 20:58:56 UTC
That's basically what Ark does, but it's not immune to confusion of a different form. See Bug 426499.
Comment 24 Philipp Maierhöfer 2022-06-21 21:31:14 UTC
As is described there, this is a matter of highlighting.

In Ark (I'm on 22.04.2), the entire line is clickable (and highlighted), but only the name is draggable, which is inconsistent in the described sense of space belonging to a specific object.

Following my suggestion, only the Name column should be clickable & draggable. And to indicate that, only that column should be highlighted (rule: highlight the area that "belongs" to the item). Downside: we loose the visual accentuation of the rest of the row. Thanks to the alternating background colours in Dolphin's details view I'd find this acceptable (there is also the suggestion of different highlighting styles/colours).

Of course in a perfect world all file listings in KDE applications would behave in the same way.
Comment 25 Satyam 2022-06-24 02:06:45 UTC
(In reply to Nate Graham from comment #1)
> This is the intentional new approach in Dolphin. It was done to implement a
> very long-standing request: Bug 181437.
> 
> I know it's a change, but I think you might like it if you give it a chance.

I see a logic of selecting the whole line, there was a case where you had to maneuver to select your file. but it turns out to be a severe regression of usability. Now the maneuvering has increased.  It takes away usability in unselecting files, in cutting and pasting, and in letting the tooltips get out of the way.  Instead of having all the non filename space to unselect files, copy or paste, or let tooltips hide I am forced to tediously navigate to a small area at the beginning of the line. This is a major increase in time and coordination. The useability and flow of working with dolphin just significantly decreased.
Comment 26 Richard Ullger 2022-06-24 13:11:48 UTC
In dolphin 22.04.2, utilising the blank column on the left hand side of the window fixes all my issues.

- Deselecting files
- Clicking in the blank column to select a pane in split view
- Right-click to paste a file into the directory being viewed
- Right-click a directory in the list and select paste file to paste a file into that directory
- Drag and drop a file into the directory being viewed
- Drag and drop a file over a directory in the list to paste the file into that directory
Comment 27 Satyam 2022-06-24 14:20:59 UTC
(In reply to Richard Ullger from comment #26)
> In dolphin 22.04.2, utilising the blank column on the left hand side of the
> window fixes all my issues.
> 
> - Deselecting files
> - Clicking in the blank column to select a pane in split view
> - Right-click to paste a file into the directory being viewed
> - Right-click a directory in the list and select paste file to paste a file
> into that directory
> - Drag and drop a file into the directory being viewed
> - Drag and drop a file over a directory in the list to paste the file into
> that directory

There are two problems with that, it's clumsy having to maneuver to such a small area and it takes away precious filename real estate.
Comment 28 pier andre 2022-06-25 17:13:30 UTC
(In reply to Richard Ullger from comment #26)
> In dolphin 22.04.2, utilising the blank column on the left hand side of the
> window fixes all my issues.
> 
> - Deselecting files
> - Clicking in the blank column to select a pane in split view
> - Right-click to paste a file into the directory being viewed
> - Right-click a directory in the list and select paste file to paste a file
> into that directory
> - Drag and drop a file into the directory being viewed
> - Drag and drop a file over a directory in the list to paste the file into
> that directory

Yes, also if you use an empty column on the right, but it is still very unconfortable and as Satyam says it takes away precious filename and other informations like data or owner real estate.
another way that partially weaken the unconfortability is to set the systemsettings>window action>right clic to only activate and rise and to not pass the click, but it imply to change the universal behaviour to leftclick to a window to rise only
Comment 29 Andreas Sturmlechner 2022-07-06 10:06:57 UTC
I complained when testing the beta, and I am considering the empty column workaround a joke.

I was a single-click user. Now I switched to double click.
Comment 30 ehrich.weiss 2022-07-15 17:19:05 UTC
*** Bug 454636 has been marked as a duplicate of this bug. ***
Comment 31 Mathias 2022-07-29 21:15:48 UTC
Another usage scenario that cries for making the old behaviour at least available as an option again:

I've been using 1) single-click and 2) split screens in 3) detailed list view for ages, and I use the navigation buttons (up and back) or the mouse controls a lot to navigate through my folder structure. And for doing that I need to change focus between the two split lists a lot. And I switch between the two lists by clicking in empty areas - the biggest ones are usually those after the filenames. The small empty column at the start is - too small.

So please make it an option if you don't like to revert to the old behaviour. Until this change Dolphin was such a great file manager.

(Switch to double-click is not an option, than I could have stayed with Windows 25 years ago  ;))
Comment 32 Satyam 2022-07-29 21:50:04 UTC
This update abandons the way dolphin has worked for the entirety of it's existence.  It's not true to make a change to a fundamental way something has functioned for many years and say that's fixing a bug.  This is not a bug fix, it's a reduction of function.  KDE introduced me to single click in 3.5. Turns out there's a major efficiency with it. Now you're abandoning my years of use in favor of an idea that it's a more correct way.  For years KDE has offered the most efficient work flow.  For the first time ever I'm finding myself being disrupted the way I'm used to by Microsoft and Apple.
Comment 33 Felix Ernst 2022-07-30 00:30:21 UTC
(In reply to Mathias from comment #31)
> I've been using 1) single-click and 2) split screens in 3) detailed list
> view for ages,

It seems like people with this combination are disrupted the most by the full row activation area. From what I have seen so far, most of the remaining strongly negative feedback to this change is from people in this user group.

The problem is mostly about switching the active view. Before the full row highlight change, switching the active view by mouse was done by clicking not-directly-on-an-item which also cleared the selection. Now one can only switch the active view by either clicking the resizable padding on the sides or by drawing a small selection rectangle to the right of a file name. I agree that this requires a bit more effort. However it is debatable if it is unreasonable to expect users to click the side padding area and to resize it if clicking it seems to require too much effort.

I wonder if there is another way in which we could make switching the active view easy that wouldn't get tripped up by the full row highlight. I guess not even the setting to switch the active view by using the "tab" key would be a complete solution because it also requires users to get used to it and isn't a great default for blind users. It would be best of course if we could find a solution that doesn't require any user to change a setting at all.

Consuming the first click on an inactive view just to activate it but not to activate clicked items/rows might also potentially be unintuitive. Double-click users don't seem to mind this though. Ideas welcome.

Having a setting to turn off full row highlight just because we can't figure out how to make switching the active pane comfortable would be a bit paneful. I am not really considering the unselecting of items as a big issue anymore because users unselect way less than they activate items so the usability benefit of having larger click areas for activation more than evens out the drawback of unselecting requiring more effort. This is true to me even if I take the initial learning curve into account.

> and I use the navigation buttons (up and back)

Clicking "Up" can be replaced by clicking the enclosing folder in the location bar but I guess opensuse has the "Up" button by default for a reason. It would be better if users didn't need to change their ways too much.

I always click the "Back" button on my mouse to go "Back" without having to change the active view first. But not everyone does this or has such mouse side buttons so changing the active view first is necessary for many users.

> or the mouse controls a lot to navigate through my folder structure.

Not quite sure what you mean. Mouse controls work without changing the active view first so this shouldn't have become any more difficult. Actually it should be easier because the click target for opening a folder has increased.

@Satyam: Not sure if you are aware, but most of the issues you have pointed out in comment #25 have already been addressed. Cutting and pasting has been fixed to work pretty much as before. The bug about tooltips is tracked separately and can be fixed separately of this bug report. Please don't compare KDE to Microsoft and Apple as long as the regressions happen because we are fixing popular bugs. Sensationalism doesn't help here.
Comment 34 Mathias 2022-08-03 07:22:10 UTC
(In reply to Felix Ernst from comment #33)
> (In reply to Mathias from comment #31)
> > I've been using 1) single-click and 2) split screens in 3) detailed list
> > view for ages,
> It seems like people with this combination are disrupted the most by the
> full row activation area. 

Full ack. And there's a pattern here I guess. In this setup you have the most information per square inch, control, speed and flexibility in sorting etc. It is not only about the probably amusing fact that people like me are used to a Midnight (or Norton;)) Commander style, detailed-listed, split view since the days before graphical UIs became common. It is about productivity. Same thing with single click: Twice as fast ;) 
I sincerely hope KDE and Dolphin keeps us in mind in the development. Because this is great software I am very thankful for.

> > and I use the navigation buttons (up and back)
> Clicking "Up" can be replaced by clicking the enclosing folder in the
> location bar 

Not if you are using an editable location bar, like me (but this is probably something where you could actually get me to change a behaviour, because it is only one click away to switch to a clickable folder hierarchy).

> I always click the "Back" button on my mouse to go "Back" without having to
> change the active view first. But not everyone does this or has such mouse
> side buttons so changing the active view first is necessary for many users.

In fact, I do have these side buttons under my thumb and use them a lot.
 
> > or the mouse controls a lot to navigate through my folder structure.
> Not quite sure what you mean. Mouse controls work without changing the
> active view first so this shouldn't have become any more difficult. 

I mean exactly the side button of the mouse you mentioned. And yes, I do not have to change the active view in this case because the mouse-back-button always affects the view pane that is under the cursor. Which is great and perfectly intuitive.
But still: on a laptop with a touchpad but without multi-button-mouse dolphin's back-button is still needed - along with an easy way to change the active view of a split screen.