Bug 312834 - closing split view closes the currently focused view instead of the inactive
Summary: closing split view closes the currently focused view instead of the inactive
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: split view (show other bugs)
Version: 2.1.97
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
: 297666 327002 360159 361095 382823 396460 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-07 17:26 UTC by Daniel Kreuter
Modified: 2020-07-19 11:08 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In: 19.03.80


Attachments
Change the meaning of the Close button (1.85 KB, patch)
2017-03-24 01:02 UTC, Christoph Feck
Details
Improvement of attachment 104707 (1.89 KB, patch)
2017-07-24 14:06 UTC, Oleg Solovyov
Details
attachment-847-0.html (3.28 KB, text/html)
2017-08-03 10:34 UTC, Thomas
Details
attachment-13410-0.html (1.30 KB, text/html)
2017-08-05 04:12 UTC, Thomas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Kreuter 2013-01-07 17:26:31 UTC
Instead of closing the inactive view while split mode was open, dolphin closes the currently active one, which is the opposite a user would expect.

This is a wish of a change, so please leave a comment if you find the current behavior strange, too.

Reproducible: Always
Comment 1 Todd 2013-01-09 11:07:34 UTC
*** This bug has been confirmed by popular vote. ***
Comment 2 jos poortvliet 2013-01-09 16:50:53 UTC
The icon correctly shows what action will happen. As all buttons act on the active view (back, forward, change view etcetera) it is logical that this button, too, acts on the active view.

As you can argue what the button should do in both directions (there is no obviously correct one), it is pointless to change it.

Moreover, ALL current Dolphin users are used to this. Changing this from under them is gonna create a huge amount of confusion and issues and extra bugreports.  So if I had down votes I would use them now ;-)

Note that I'm not a developer nor do I speak for anyone working on Dolphin...
Comment 3 phanisvara das 2013-01-09 21:11:41 UTC
why not create an additional action, "close inactive view," which can be assigned to a similar, but different button?
Comment 4 Ettore Atalan 2013-01-10 00:13:18 UTC
In my opinion a very good idea. A completely unambiguous and logical behaviour.
Comment 5 phanisvara das 2013-01-10 01:09:20 UTC
i like even better the idea someone had on G+, to add a small close button to each view. but i think that's more invasive into the UI. personally, i'm happy as it is (close the active view).
Comment 6 Daniel Kreuter 2013-01-10 08:16:32 UTC
(In reply to comment #5)
> i like even better the idea someone had on G+, to add a small close button
> to each view. but i think that's more invasive into the UI. personally, i'm
> happy as it is (close the active view).
An additional close button at each view would be a nice and clean solution but may result in many code which needs to be maintained. I will discuss thia idea with Frank what he thinks about it.
Comment 7 Frank Reininghaus 2013-01-10 08:41:54 UTC
(In reply to comment #3)
> why not create an additional action, "close inactive view," which can be
> assigned to a similar, but different button?

As I explained in the thread on the kfm-devel mailing list, I think that this would bring usability problems. Currently, the action's name switches between "Split" and "Close". What short, meaningful name could a new action get to avoid confusion?

Moreover, having two different split/close actions would also require more code and thus make long-term maintenance harder.

(In reply to comment #4)
> In my opinion a very good idea. A completely unambiguous and logical
> behaviour.

Also the current behaviour is completely unambiguous and, as Jos pointed out, maybe even more logical than closing the inactive view.

(In reply to comment #5)
> i like even better the idea someone had on G+, to add a small close button
> to each view. but i think that's more invasive into the UI.

I'm also concerned about the UI invasiveness. Offering multiple ways to close views does not improve the usability IMHO. Moreover, the new 'close button' would probably be placed next to some other UI element, like the 'check' button that switches the location bar from 'editable' to 'breadcrumb' mode, and thus make it hard to see at first sight what the button is actually about.
Comment 8 Daniel Kreuter 2013-01-10 09:49:37 UTC
Another option I'm currently thinking of is to add a new shortcut to dolphin which closes the inactive view instead of the active one like it's done in firefox for switching tabs.
Comment 9 Ryan Muller 2013-02-20 23:34:38 UTC
In Qt Creator, the Window->Remove All Splits option keeps the focus on the current document, closing others. The Dolphin behavior is inconsistent with this. The Nemo file browser, used in Cinnamon, has behavior opposite that of Dolphin, resulting in a much more intuitive way to interact with the split pane. 

Admittedly, Kate's behavior is consistent with that of Dolphin. However, in my experience, one does not close a split pane in Kate quite as often as a split pane in Dolphin. Split panes are often for comparing or copying, and it's much more common to compare or copy folder contents as opposed to source code.

@jos poortvliet: To say that *all* Dolphin users are used to the current behavior is a bit of a stretch. Many users may not even be aware of the feature, and I'm sure it would be interesting to see the stats on how many people actully use it. Even people who are used to the opposite workflow would find their flow improved, as the switched behavior would remove the need for a mouse click when switching. Ten minutes with the new behavior would be enough to adapt.

Also, I prefer the keyboard over the mouse. From a keyboard perspective, it is useful to hit F3 to pop up the extra pane, then again to close it when it's no longer needed. This keeps the focus of the workflow consistent. In contrast, Dolphin awkwardly switches focus to the right panel on the split action. If the user does not look at the icon, but rather uses the keyboard, then it will not be clear which panel is closing. This snares me personally at least once a day, even though I've been using Dolphin constantly for a couple months now. I've tried to adapt to the current configuration, but it's just not intuitive, which is why I'm writing.

I think the new button could simply be called "unsplit" or, for more description, "close opposite". The icon would make it clear as to what the effect would be, so mouse-users would be aware of the change.

The conversation on the mailing list asked if anyone had written a blog post on the topic. I mentioned Dolphin in a post about Kubuntu, and how it could be improved. The post is available at http://blog.ramuller.com/kubuntu-is-awesome/ .

Best,
--Ryan
Comment 10 Frank Reininghaus 2013-02-21 09:05:39 UTC
(In reply to comment #9)

Some of what you say certainly makes sense, but comparing a Qt Creator action which is explicitly called "Remove *All* Splits" to our case really makes no sense at all. If you remove *all* splits in an application which allows multiple splitting, there is just no way to close the current view - how would you choose the view which should remain?

Concerning the question what is more intuitive: I see that one can argue about that - even considering that all other actions are also applied to the *current* view, which also makes it logical to apply the "Close" action to the current view.

However, every behaviour change (even if it makes the behaviour more intuitive) brings larger problems that most people think. Everyone who uses the feature got used to a certain workflow (if you want to keep the current view, first switch to the other one, then close), which would be disrupted if any change is made. This can become a huge annoyance in some situations.

Just one example how a small change that looks fine can cause trouble: some time ago, Konsole changed the shortcut to open a new tab from Ctrl+Shift+N to Ctrl+Shift+T. Makes perfect sense and is more intuitive, isn't it? Unfortunately, this change drove me insane quite a few times because the KDE installed at work is always a couple of versions behind the one I have at home, so there were different shortcuts for an action that I perform quite often. Yes, I know that I can change shortcuts manually, but then I would have to resolve conflicts with the new action that Ctrl+Shift+N performs, and I would have problems as soon as I sit in front of somebody else's machine, therefore, I prefer to stick with the defaults. Another problem is now that Yakuake, which I also like and use a lot, apparently picked up the "New Tab" shortcut that Konsole had before the change, so these applications, which are quite similar, do quite different things when pressing Ctrl+Shift+T/N. To sum up: I see that changing that shortcut made sense, but it has annoyed me quite a few times already, and I doubt that the benefits of that change outweigh the trouble that I and other users had and still have.

I hope that this example shows that making behaviour changes can cause trouble for users, and that there must be an extremely good reason to make a change that will break workflows that people got used to.
Comment 11 Ettore Atalan 2013-02-21 12:32:48 UTC
Why not adding a new shortcut (e.g. Shift+F3) and menu item ("Close inactive view") for closing the inactive view?

The current menu item can be renamed to "Close active view (F3)" by keeping the current shortcut (F3) and the behaviour should be okay and clear for all users.


Regards,
Ettore
Comment 12 Ryan Muller 2013-02-21 13:05:14 UTC
Good points, Frank, and thank you for commenting on the blog post as well.

Turns out Qt Creator's "Remove Current Split" is consistent with Kate's and Dolphin's behavior--I guess I didn't do my homework enough before posting.

I also agree with Ettore, that a new keyboard shortcut could be added with minimal impact. Menu item may or may not be necessary, depending on how people feel about cluttering the interface.
Comment 13 Daniel Kreuter 2013-02-21 13:12:51 UTC
The shortcut would be quite comstistent since there are other programs with similar brhavior o.e firefox for switching tabs or window switching on the desktop
Comment 14 Weng Xuetian 2013-02-21 13:29:00 UTC
I guess the real problem is how user use split view.

Currently, if user split the view -> use split view to browse to another folder -> drag a file from the origin view to the new view -> a menu pop up and ask you about (move, copy etc), you select one and done.

Now, which view would user usually want to keep? As for me is the destination because it's usually a sftp, usb disk or something similar.

In order to close that with current button, either:
1. close the inactive view
2. or move focus to the destination, then destination will be the active one. Currently dolphin doesn't move the focus on to the destination, which might be the real problem for this.

Close the "active" view is IMHO based on the idea: "The last place I used need to be closed", but here I think the copy destination is the last place that the operation touches, so the real problem maybe not close view but need to move focus onto drag destination.

BTW, as for break workflow: http://xkcd.com/1172/ people will always break others' workflow.
Comment 15 Frank Reininghaus 2013-02-22 09:59:19 UTC
(In reply to comment #11)
> Why not adding a new shortcut (e.g. Shift+F3) and menu item ("Close inactive
> view") for closing the inactive view?

I already said something abou that in comment 7.

(In reply to comment #14)
> 2. or move focus to the destination, then destination will be the active
> one. Currently dolphin doesn't move the focus on to the destination, which
> might be the real problem for this.

Interesting idea. I never thought about this.

> BTW, as for break workflow: http://xkcd.com/1172/ people will always break
> others' workflow.

Thanks for sharing that :-)
Comment 16 razinov.a.u 2013-03-22 20:00:18 UTC
I've just understood completely the logic of closing/opening an additional panel. Assume we have a shortcut F3 for this action.

Current logic:
1. User presses F3 - open panel.
2. New panel appears and become active.
3. User works with panels.
4. User presses F3 - close panel.
5. Current (active) panel is closed.

Good straightforward logic. But. It is not user friendly. When user has worked with active panel for long and wants now to close other not necessary panel, he presses F3. Voila. There is an unexpected behavior for user - he has just closed an active panel.

I think it is a good idea to open new tab as inactive.
So sequence of user's actions will be like so:
1. User presses F3 - opens panel.
2. New panel appears and become inactive.
3. User works with panels.
4. User presses F3 - closes inactive panel.
5. Current (active) panel is closed.

This way is more user friendly and is still straightforward. There is no need to modify user interface, only to change few lines of code.
Comment 17 Weng Xuetian 2013-06-05 21:10:22 UTC
Git commit 08eae43abd4eb87dc014b5f86fe34e762604cecc by Weng Xuetian.
Committed on 05/06/2013 at 23:07.
Pushed by xuetianweng into branch 'master'.

move focus to another view upon drop

When user drag and drop to another splitted view, the view will be activated,
thus if user close the split view, the view will be closed, while this is
usually the case when user copy file to remote/removable media.

REVIEW: 110167

M  +2    -0    dolphin/src/views/dolphinview.cpp

http://commits.kde.org/kde-baseapps/08eae43abd4eb87dc014b5f86fe34e762604cecc
Comment 18 Christoph Feck 2013-11-01 16:34:17 UTC
*** Bug 327002 has been marked as a duplicate of this bug. ***
Comment 19 sunwebrw 2015-02-06 20:34:05 UTC
What razinov.a.u@gmail.com said, easy and clean. All file browsers i know that have such option share the same behaviour except for Dolphin.
If there is a care for old users that got used to old behaviour ok, leave default like this. But you could also make a simple option in the Dolphin settings to change the behaviour.

Dolphin Preferences -> View Modes -> "Split" tab will have an option to change behaviour.

Note: New users would really like this new Split mode by default more than the old one. And old KDE users such as myself would also wellcome the change. But even if its not going to default an option to change Split mode behaviour would be more than enough. Thank you.
Comment 20 andydecleyre 2016-01-07 22:58:09 UTC
Even if you don't change the default behavior, 
even if you don't enable changing the behavior in the settings, 
even if you don't add another keyboard shortcut for the more intuitive behavior (closing the pane _not_ being actively used),

please just add another button in the Configure Toolbars dialog (that a user would have to seek out or stumble upon) that opens a second pane but _doesn't_ activate it, and closes the _inactive_ pane if two are already open.
Comment 21 andydecleyre 2016-01-07 23:32:12 UTC
OK, rereading this three year long discussion, I think I understand that the reason my last comment's reiterations of previous suggestions have not been acted on is:

"Currently, the action's name switches between 'Split' and 'Close'. What short, meaningful name could a new action get to avoid confusion?"

So, let's brainstorm:

Split | Close Other
Split | Crop
Single | Dual
Split | Close [Left | Right]
Split | Maximize
Split | Fill
Split | Grow
Split | Widen
Split | Only
Split | Focus
Split | Focalize
Wane | Wax
Split | Expand
Split | Swell

I think "Split | Swell" is my favorite so far. The words are pleasantly symmetrical. My next choices are probably Grow, Fill, Expand.
Comment 22 Ettore Atalan 2016-01-07 23:43:00 UTC
(In reply to andydecleyre from comment #20)
> Even if you don't change the default behavior, 
> even if you don't enable changing the behavior in the settings, 
> even if you don't add another keyboard shortcut for the more intuitive
> behavior (closing the pane _not_ being actively used),

You'd better use another file manager due to the lack of willingness to consider user needs. It's more a KDE problem than a technical problem, anyway.
Comment 23 andydecleyre 2016-01-18 22:21:10 UTC
The version's a bit out of date these days. Can someone with permissions please update it from 2.1.97 to 15.12.1?
Comment 24 andydecleyre 2016-02-03 20:27:12 UTC
Maybe a solution that would please users but also be palatable for devs:

Add a button to open/close the _right_ pane, and another optional button to swap panes. That can be clear, succinct, and highly functional.
Comment 25 Christoph Feck 2016-03-07 02:10:16 UTC
*** Bug 360159 has been marked as a duplicate of this bug. ***
Comment 26 Christoph Feck 2016-03-28 22:38:51 UTC
*** Bug 361095 has been marked as a duplicate of this bug. ***
Comment 27 andydecleyre 2016-06-30 20:01:15 UTC
Can someone with permissions please update the version from 2.1.97 to 16.04.2 ? A lot of versions happen in three and a half years.
Comment 28 fgf 2017-03-23 15:31:01 UTC
I do not understand, why a behaviour that annoys and frustrates many people is apparently ignored or even defended for no good reason. I can't count the occasions where I closed the wrong view and had to navigate again to the previous location. 

The "arguments" put forward to defend the completely counter-intuitive behaviour of closing the active view are not convincing. I cannot help but assume that the real reason is stubbornness on the side of the developers. This change (either as an option, or an additional/alternative key-binding) is simple and non-intrusive for those that are used to old behaviour or who consider this for whatever reason as "logical". 

I again plead for the changes proposed in this thread. The current behaviour is a BUG not a feature and should be fixed.
Comment 29 Denis Prost 2017-03-23 15:52:42 UTC
I totally second this
Comment 30 Ettore Atalan 2017-03-23 18:12:25 UTC
(In reply to fgf from comment #28)
> I do not understand, why a behaviour that annoys and frustrates many people
> is apparently ignored or even defended for no good reason.

It's KDE ...
Comment 31 Christoph Feck 2017-03-24 01:02:24 UTC
Created attachment 104707 [details]
Change the meaning of the Close button

Yes, it is KDE, a community of volunteers. Adding more comments to a feature request won't magically change code, especially when there was no consensus.

Here is a patch. It changes the meaning of the "Close Split View" toolbar button from "Close Active Split View" to "Close Inactive Split View". I did not search for descriptive texts, so these might be wrong now.
Comment 32 Oleg Solovyov 2017-07-24 14:06:56 UTC
Created attachment 106825 [details]
Improvement of attachment 104707 [details]

(In reply to Christoph Feck from comment #31)
> Created attachment 104707 [details]
> Change the meaning of the Close button

Your patch is causing crash after closing LEFT view and switching to another tab (if exist).
Comment 33 Christoph Feck 2017-07-28 10:02:00 UTC
*** Bug 382823 has been marked as a duplicate of this bug. ***
Comment 34 Elvis Angelaccio 2017-08-03 08:31:07 UTC
(In reply to fgf from comment #28)
> I do not understand, why a behaviour that annoys and frustrates many people
> is apparently ignored or even defended for no good reason.  
> The "arguments" put forward to defend the completely counter-intuitive
> behaviour of closing the active view are not convincing. 

How can you tell that there are more people annoyed than people who are accustomed to the current behavior? I bet that if we change behavior, we are going to get tons of bug reports (see the already cited xkcd/1172).

And why do you think that the arguments provided by Frank are not good or convincing?

> I cannot help but
> assume that the real reason is stubbornness on the side of the developers.
> This change (either as an option, or an additional/alternative key-binding)
> is simple and non-intrusive for those that are used to old behaviour or who
> consider this for whatever reason as "logical". 

I'm against adding an option. An additional action/shortcut is the only way to fix this, imho. If anyone can provide a clean patch with unit tests, I'd be happy to review it.
Comment 35 Thomas 2017-08-03 10:34:12 UTC
Created attachment 107053 [details]
attachment-847-0.html

I really think, there is not a single person out there that truly thinks
the current behavior is good. Let's look at the workflow:

My typical split view workflow is adding the split view, because you want
to copy or compare files and then continue to work in one of the folders.
At this point the other folder becomes useless to you and that is the
reason why you want to close it.

The current behavior forces you to switch from the folder that you want to
keep, because it has the content you want to work with, into the folder
that you want to close. Then you close it and look back at the interesting
folder.

The proposed behavior is that you subconsciously recognize that the other
view is obsolete and close it without losing focus. You seemlessly continue
to work.

What are your workflows for split view? Do you support my point of view?

Thomas

Elvis Angelaccio <bugzilla_noreply@kde.org> schrieb am Do., 3. Aug. 2017,
10:31:

> https://bugs.kde.org/show_bug.cgi?id=312834
>
> Elvis Angelaccio <elvis.angelaccio@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |elvis.angelaccio@kde.org
>
> --- Comment #34 from Elvis Angelaccio <elvis.angelaccio@kde.org> ---
> (In reply to fgf from comment #28)
> > I do not understand, why a behaviour that annoys and frustrates many
> people
> > is apparently ignored or even defended for no good reason.
> > The "arguments" put forward to defend the completely counter-intuitive
> > behaviour of closing the active view are not convincing.
>
> How can you tell that there are more people annoyed than people who are
> accustomed to the current behavior? I bet that if we change behavior, we
> are
> going to get tons of bug reports (see the already cited xkcd/1172).
>
> And why do you think that the arguments provided by Frank are not good or
> convincing?
>
> > I cannot help but
> > assume that the real reason is stubbornness on the side of the
> developers.
> > This change (either as an option, or an additional/alternative
> key-binding)
> > is simple and non-intrusive for those that are used to old behaviour or
> who
> > consider this for whatever reason as "logical".
>
> I'm against adding an option. An additional action/shortcut is the only
> way to
> fix this, imho. If anyone can provide a clean patch with unit tests, I'd be
> happy to review it.
>
> --
> You are receiving this mail because:
> You voted for the bug.
Comment 36 Oleg Solovyov 2017-08-03 13:36:51 UTC
Maybe add "Close left", "Close right" buttons instead of one "Close" button?
Comment 37 Elvis Angelaccio 2017-08-03 13:57:35 UTC
(In reply to Oleg Solovyov from comment #36)
> Maybe add "Close left", "Close right" buttons instead of one "Close" button?

No, that would change the meaning of the current "Close" action, which is what we want to avoid. I'd use "Expand" or a similar name, since that's what would happen (the inactive view gets closed ==> the active one gets expanded).
Comment 38 Thomas 2017-08-05 04:12:02 UTC
Created attachment 107081 [details]
attachment-13410-0.html

Fair enough, I don't care about the name. The current behavior of split
view close is annoying me because it is constantly interrupting my
workflow.

Elvis Angelaccio <bugzilla_noreply@kde.org> schrieb am Do., 3. Aug. 2017,
15:57:

> https://bugs.kde.org/show_bug.cgi?id=312834
>
> --- Comment #37 from Elvis Angelaccio <elvis.angelaccio@kde.org> ---
> (In reply to Oleg Solovyov from comment #36)
> > Maybe add "Close left", "Close right" buttons instead of one "Close"
> button?
>
> No, that would change the meaning of the current "Close" action, which is
> what
> we want to avoid. I'd use "Expand" or a similar name, since that's what
> would
> happen (the inactive view gets closed ==> the active one gets expanded).
>
> --
> You are receiving this mail because:
> You voted for the bug.
Comment 39 andydecleyre 2017-09-30 17:40:09 UTC
So can we muster consensus on a new "Split/Expand" button and action?
Comment 40 Christoph Feck 2018-07-13 16:50:30 UTC
*** Bug 396460 has been marked as a duplicate of this bug. ***
Comment 41 Nate Graham 2018-07-13 17:05:30 UTC
Confusion over which pane will be closed definitely keeps me from using the Split feature more often.

After five years, we have not managed to achieve consensus on what the toolbar button should do, whether or not it should be configurable, or whether we should add a second (hidden by default) button that has the other behavior.

Looking through the duplicates, some people want the active pane closed, while other want the inactive pane closed. In such a circumstance, IMHO adding a user preference is the way to go, but if that's not an option, let's consider alternative ideas. Here are some:

- Add individual close buttons to each split view pane somewhere, so you can click on that pane's own close button to make sure you're closing the one you intend
- Make the "Close" button's text indicate which view it will close (e.g. "close left pane"/ "Close right pane")
- Have the "Close" button close the opposite pane when middle-clicked on (and adjust the tooltip to indicate this)
- Adjust the toolbar button's icon to make the pane that will be closed more obvious (I only just now noticed that it changes depending on which pane is focused)

Thoughts?
Comment 42 br_shadow 2018-07-13 17:09:33 UTC
It's counter-intuitive to close the active view when you press F3 again, it should close the non-active view by default and put a option somewhere if you want to reverse this (which in my opinion is not even necessary).
Comment 43 Mircea Kitsune 2018-07-13 18:12:34 UTC
The "close split view" button seems to at least be consistent now: It will always close the active view rather than having an unpredictable result. The only question remains whether it makes more sense for it to close the inactive view and keep the active one instead.
Comment 44 Christoph Feck 2018-08-02 18:28:32 UTC
Another idea: Split button has a drop-down indicator. Clicking it splits/closes the view. Holding it shows (after a short delay) a menu where you can select the view to close. This selection is remembered in settings.
Comment 45 Ettore Atalan 2018-08-03 16:32:17 UTC
My advice to you: Don't waste your time with KDE hardliners. Use another desktop environment instead of KDE.
Comment 46 Nate Graham 2018-08-03 16:37:52 UTC
Ettore, this is a bug tracker, not a complaint box. I understand you're frustrated, but dumping negativity won't get this issue fixed any faster. In fact, it's likely to have the opposite effect since volunteer developers are easily demoralized by criticism. If you want to have a positive impact, you could contribute to our brainstorming regarding possible options.
Comment 47 Ettore Atalan 2018-08-03 16:51:10 UTC
This issue was reported in 2013. You don't have to be a pessimist to realize that nothing will happen here.
Comment 48 Nate Graham 2018-08-03 16:56:03 UTC
I have personally (and recently) fixed issues that were 14 years old. Anything's possible. But, it becomes less possible when someone's seemingly trying to sabotage the process by posting discouraging comments. If you want this fixed, negativity makes it *less* likely, not more. See https://community.kde.org/Get_Involved/Bug_Reporting#Bug_tracker_etiquette

You catch more flies with honey then vinegar, that's all I'm trying to say. :)
Comment 49 Chris Holland 2018-08-03 17:49:57 UTC
I'd prefer a configuration checkbox to switch between behaviours. However:

> I'm against adding an option. An additional action/shortcut is the only
> way to fix this, imho. If anyone can provide a clean patch with unit tests,
> I'd be happy to review it.

So I guess that means we need a new "Action" like the Shift+F3 "Close Other".

Shift+F3 could also be a "toggle" action like F3. So users could simply swap the shortcuts and ignore the other shortcut. The toolbar button could be hidden by default. The Menu Item would be a duplicate however (when not in split view). Not sure if we can "hide" the second menu item without disabling the shortcut.

I've been using the patch posted above for a while now.
https://github.com/Zren/dolphin/commit/2b546cce997daf0c2dd9ac597123138685cec921
Comment 50 andydecleyre 2018-08-03 18:02:07 UTC
I think I'd be happy if any one of the suggestions were implemented, but my preference at this point is to have the close pane button always close the right side, with an additional action to swap the panes. That should keep everything simple, well defined, and predictable. 

I don't know if this reversed for RTL users.
Comment 51 Nate Graham 2018-08-10 17:12:44 UTC
(In reply to Chris Holland from comment #49)
> I'd prefer a configuration checkbox to switch between behaviours. However:
> 
> > I'm against adding an option. An additional action/shortcut is the only
> > way to fix this, imho. If anyone can provide a clean patch with unit tests,
> > I'd be happy to review it.
> 
> So I guess that means we need a new "Action" like the Shift+F3 "Close Other".
> 
> Shift+F3 could also be a "toggle" action like F3. So users could simply swap
> the shortcuts and ignore the other shortcut. The toolbar button could be
> hidden by default. The Menu Item would be a duplicate however (when not in
> split view). Not sure if we can "hide" the second menu item without
> disabling the shortcut.
> 
> I've been using the patch posted above for a while now.
> https://github.com/Zren/dolphin/commit/
> 2b546cce997daf0c2dd9ac597123138685cec921

Would you like to submit this as a patch?
Comment 52 Gastón Haro 2018-10-01 22:59:21 UTC
Just because the action is called "Close" and "buttons always act on the active view" we choose to keep an awkward behavior like this only for the sake of consistency.

Well, sometimes exceptions are very welcomed. So here is my proposal, we could try being consistent with user friendliness instead. That could probably work out pretty well.
Comment 53 Nadir 2018-12-23 22:26:05 UTC
I had the same need. It was so annoying to me every hour of every day. 

A patched version now exists : https://forum.kde.org/viewtopic.php?f=223&t=151449

Patch done, based on Dolphin 18.08.1.

An executable version of Dolphin (that I myself use) available in Arch AUR : 

https://aur.archlinux.org/packages/dolphin-split-view-the-right-way/

Source code: 
https://github.com/boussou/dolphin-split-view-the-right-way


I hope one day the KDE team will accept to add the feature (giving choice to users)
Comment 54 Nadir 2018-12-23 22:26:41 UTC
I had the same need. It was so annoying to me every hour of every day. 

A patched version now exists : https://forum.kde.org/viewtopic.php?f=223&t=151449

Patch done, based on Dolphin 18.08.1.

An executable version of Dolphin (that I myself use) available in Arch AUR : 

https://aur.archlinux.org/packages/dolphin-split-view-the-right-way/

Source code: 
https://github.com/boussou/dolphin-split-view-the-right-way


I hope one day the KDE team will accept to add the feature (giving choice to users)
Comment 55 Nate Graham 2018-12-23 22:38:57 UTC
Personally I find it quite acceptable to have this be configurable, and I hope you submit a patch using http://phabricator.kde.org. I would be happy to help you if you've never done it before.


P.S. in terms of the user interface, you could make a new section like so, since there will be two split-view-related items:



  Split Views: [] Switch between views with tab key
               [] Close active view when toggling off

Miscellaneous: [] Show tooltips
               [] Show selection marker
               [] Rename inline
Comment 56 Nadir 2018-12-24 12:49:01 UTC
Hi,
Thanks for your answer.
No I never used phabricator. 

You seem to say that if a patch is submitted, it will be accepted. That is a good motivator to spend time on it.
Comment 57 Nate Graham 2018-12-24 15:17:02 UTC
(In reply to Nadir from comment #56)
> Hi,
> Thanks for your answer.
> No I never used phabricator. 
> 
> You seem to say that if a patch is submitted, it will be accepted. That is a
> good motivator to spend time on it.

I wouldn't say it's guaranteed, but I'd support you. :)
Comment 58 Nadir 2018-12-26 20:25:01 UTC
Just for information, will it need to port the patch to the last version of Dolphin before proceeding?

The current patch is on Dolphin 18.08.1, would it be ok?
Comment 59 Nate Graham 2018-12-26 20:28:03 UTC
The patch will need to be based on master, since this is a new feature. you can re-base it in your local checkout using `git pull --rebase origin/master`
Comment 60 Nadir 2019-01-08 04:55:31 UTC
Patch posted. 


Close inactive split view when toggling off
https://phabricator.kde.org/D18040
Comment 61 Nate Graham 2019-01-08 20:18:06 UTC
Thanks! I will review it today or tomorrow.
Comment 62 Elvis Angelaccio 2019-02-16 15:15:44 UTC
Git commit 92368c1e4df9ea09e50c6480c2f72b78416e3244 by Elvis Angelaccio, on behalf of Angelo Oliveira Jr.
Committed on 16/02/2019 at 15:09.
Pushed by elvisangelaccio into branch 'master'.

Add option to choose which view to close

Summary:
This Diff make configurable which view will close when toggling off
the split view mode, if it's the active one or the inactive one.

A new checkbox was added to the Dolphin configuration window,
and defaults to the original behavior.
FIXED-IN: 19.03.80

Test Plan: {F6535432}

Reviewers: ngraham, #dolphin, elvisangelaccio

Reviewed By: ngraham, #dolphin

Subscribers: elvisangelaccio, cfeck, kfm-devel

Tags: #dolphin

Differential Revision: https://phabricator.kde.org/D18040

M  +1    -1    src/dolphinmainwindow.cpp
M  +17   -7    src/dolphintabpage.cpp
M  +4    -0    src/settings/dolphin_generalsettings.kcfg
M  +8    -0    src/settings/general/behaviorsettingspage.cpp
M  +1    -0    src/settings/general/behaviorsettingspage.h

https://commits.kde.org/dolphin/92368c1e4df9ea09e50c6480c2f72b78416e3244
Comment 63 postix 2020-07-19 11:08:23 UTC
*** Bug 297666 has been marked as a duplicate of this bug. ***