Bug 453198 - Switching to a pane in Details view mode results in a file opening
Summary: Switching to a pane in Details view mode results in a file opening
Status: RESOLVED DUPLICATE of bug 453700
Alias: None
Product: dolphin
Classification: Applications
Component: panels: folders (show other bugs)
Version: 22.04.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-29 16:08 UTC by thwrnr0
Modified: 2022-07-16 09:58 UTC (History)
3 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 thwrnr0 2022-04-29 16:08:46 UTC
SUMMARY
After my recent update, I can't easily switch to a pane that is in Details (table) view mode.

STEPS TO REPRODUCE
1. Open Dolphin in split view mode.
2. Set one of the panes to the Details view mode.
3. In the Details pane, navigate to a folder or resize the window so that the pane is full of files with no white space below.
4. Switch focus to another pane.
5. Left-click on empty space in the Details pane (to the right from a file name).

OBSERVED RESULT
The file to the left from the mouse cursor opens because hovering over the empty space of a table row has the same effect as hovering over the file name on the left side of the row.

EXPECTED RESULT
Focus switches to the Details pane and nothing else happens.

SOFTWARE/OS VERSIONS
Linux: openSUSE Tumbleweed, 5.17.4-1-default
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
It can be bypassed by right-clicking (opens menu) and then left-clicking (closes menu) on the empty space, but that's annoying.
Comment 1 Johannes Schmidt 2022-05-11 19:08:11 UTC
This has been bothering me too. It's very counter intuitive behavior considering that in all other modes as in details mode mode, clicking the empty space just selects the pane.

A related problem is that if you have a directory containing a long list of directories you have no place to drag and drop files/folders into, and no place to right-click to create new folders or files. It will always drop into or create the file inside the directory whose row is under the cursor instead of the directory displayed.

In my opinion, clicking (or dragging onto) anything but the file/directory name and icon should not open the file or directory.
Comment 2 Johannes Schmidt 2022-05-11 19:15:21 UTC
(In reply to Johannes Schmidt from comment #1)
> [...] and no place to right-click to create new folders or files. 
Sorry, I just realized that this is false, right-clicking and creating files/folder works as expected. 

Which in my eyes makes this even more inconsistent. Why does left-clicking and drag-dropping into empty space select/open a file/folder and right-clicking empty space does not?
Comment 3 thwrnr0 2022-05-25 22:32:22 UTC

*** This bug has been marked as a duplicate of bug 453700 ***
Comment 4 Felix Ernst 2022-07-15 18:08:21 UTC
I am trying to understand the exact use case here.

Can you explain why you want to switch the active pane but don't want to click on an item or make a selection in the pane you are clicking? What do you want to accomplish by switching the active pane?
Comment 5 Johannes Schmidt 2022-07-15 21:06:41 UTC
(In reply to Felix Ernst from comment #4)
> Can you explain why you want to switch the active pane but don't want to
> click on an item or make a selection in the pane you are clicking?

Just to clarify:

The most relevant use-case to me is quickly changing the directory of the terminal widget to the other pane to do run a command in the directory opened in that pane. Or more generally, basically any toolbar action that only acts on a single pane, like searching, setting view mode, toggling previews, or closing the selected pane.

For me personally, the solution of adding the "Leading Column Padding" was sufficient. I'm not the reporter of this duplicate issue, but for me personally all issues have been resolved with that.
Comment 6 Felix Ernst 2022-07-16 09:58:44 UTC
Thanks for clarifying!

>The most relevant use-case to me is quickly changing the directory of the terminal widget to the other pane to do run a command in the directory opened in that pane. Or more generally, basically any toolbar action that only acts on a single pane, like searching, setting view mode, toggling previews, or closing the selected pane.

For all the example actions given above, aiming at the Side Padding is not even required because dragging a small selection rectangle on a row would also work. That would lead to marking an item as selected but for all of the examples you have given that wouldn't matter. I see the point though that one might not want to have an item selected even if there is no concrete downside to this currently. We have the new Side Padding for this.

>The most relevant use-case to me is quickly changing the directory of the terminal widget to the other pane to do run a command in the directory opened in that pane.

Not sure if this is relevant here, but I'll mention that there is a way to do this without even taking the hands of the keyboard i.e. "Ctrl+Shift+F4" to go to the active view, then "Tab" (if the "Tab to change active pane" setting is enabled), then "Ctrl+Shift+F4" again to go back to terminal. I admit though that this isn't very discoverable so using the mouse for that seems easier. I feel like we should change it so "Tab" as part of the normal tab order should change to the next view and "Shift+Tab" should change back even if the "Tab to change active pane" setting is disabled. That would make this slightly easier.

>For me personally, the solution of adding the "Leading Column Padding" was sufficient. I'm not the reporter of this duplicate issue, but for me personally all issues have been resolved with that.

Glad to hear that!