Clicking on file in tree view that isn't open sets focus on editor

[adamreisnz]

When I click a file in tree view that isn't open yet, focus is shifted to the editor (file contents). This is problematic, as I relied on clicking on a file for the focus to stay on the tree view, so that I could hit m to rename the file.

I suspect this may have to do with the refactoring around files not being opened as temporary files anymore?

Atom version 1.6.0-beta5, OS X 10.11.2.

[lee-dohm]

This is a duplicate of #199. Please see the comments and suggested packages there. Let us know if you have any questions!

[adamreisnz]

@lee-dohm no, it is not a duplicate of that issue.

That issue talks about preventing the files from opening on a single click, I don't mind the files being opened, I just want the focus to stay on the tree view.

This didn't use to happen in Atom 1.4.x and 1.5.x and earlier, it only started in 1.6.x.

[lee-dohm]

My mistake. Thanks for the correction 😀

As an aside, including repro steps can help clarify these differences.

[adamreisnz]

No worries, sorry I thought it was clear. Let me specify:

1. Open a project, close all file tabs
2. Single click on a file in the tree view
3. Press m to rename the file

Expected: the file rename dialog pops up

Actual: you type the letter m in the opened file on top, because after clicking the file focus is shifted to the editor window.

[adamreisnz]

@lee-dohm have you had some time to look into this by any chance? It's impairing my productivity a lot, as I keep hitting m and having to erase the character and make sure I click the file name twice (not double click) before I rename it.

[billyjanitsch]

Based on #740 (comment) it looks like this is actually intended behavior (introduced in e93148d, see also #742 and #682). The rationale seems to be "you can click on a file and immediately start editing it". However, I agree with @adambuczynski that this is undesirable.

The old behavior (single click to gain focus/preview, double click to open and transfer focus to the editor) aligns with Windows/OSX file explorers, most email clients, Dropbox/Drive, Sublime, etc. It's strange for Atom to diverge from such a common UX standard.

Even ignoring consistency, it seems counterintuitive that if I click on an item in a list, the list immediately loses focus, preventing me from doing anything with it (e.g. renaming/deleting/duplicating, navigating the list with arrow keys). It also introduces an awkward inconsistency in the behavior between clicking on files (editor gains focus) and folders (tree view retains focus).

@kuychaco, perhaps you could shed some light on this?

[monsterkodi]

"The tree-view losing focus on click is actually the intended behavior." Really?
I agree with the above, the usability of the tree-view is completely broken by this "feature".

[BinaryMuse]

Thanks for bringing up this issue again, all. @kuychaco and I chatted about this last night and would love to explore some options.

To set context, the current behavior is predicated on the assumption that the thing you probably want to do with a file after opening it is edit its contents. With the changes to pending pane items that landed in Atom 1.6, both single-clicking and double-clicking a file in the tree view opens the file for editing, but now in different states (i.e. pending vs. permanent). However, it's obvious here that the goal of clicking on a file is not always to edit it, but sometimes to manipulate it in other ways. We'd like to support the best of both worlds if we can.

Here are a few things we brainstormed; we're not super set on any of them, and some of them may be terrible ideas. :P We're also open to other suggestions.

1. Retain the old behavior (single-click to open a file and retain tree view focus, double-click to open a file and focus the editor) if pending pane items is disabled (via core:allowPendingPaneItems). I'm particularly curious if people who would prefer the old single-click behavior of keeping focus in the tree view even use/care about pending pane items. This would be trivial to implement.
2. Change single- or double-clicking on a tree view file to dispatch an action instead of directly calling Workspace::open (e.g. tree-view:open-selected-file and tree-view:open-selected-file-alternate). Then a small snippet of code inside init.coffee would allow folks to re-focus the tree view easily after the single-click action has been dispatched. This provides additional flexibility as people could overwrite a lot of behavior by hooking into the command dispatch, but requires people to edit their init script to get the old behavior, and is pretty complicated overall.
3. Add an option for tree view along the lines of "Focus editor upon opening a file." However, as mentioned, there are now two states a pane item can be in after opening, triggered differently by single- or double-clicking, so I'm not sure if we'd need additional options there. Perhaps something like "Focus editor upon opening a file in a pending state"? (This could go hand-in-hand with option 1.)

For simplicity and flexibility, I'm personally favoring the "Focus editor upon opening a file in a pending state" option along reverting to the old behavior if pending tabs is completely disabled; in short, it means that single-clicking would always retain tree veiw focus and double-clicking would always focus the editor, no matter whether pending items are enabled or not. Then, if and only if pending items are enabled and the new option is checked, single-clicking a file will focus the editor (the current 1.6 behavior):

• With pending tab items enabled:
  • Single-clicking a tree view entry opens the file in pending mode
    • With the new option enabled, the editor is focused
    • With the new option disabled, the tree view is focused
  • Double-clicking a tree view entry opens the file in permanent mode
    • The editor is always focused
• With pending tab items disabled:
  • Single-clicking a tree view entry opens the file in permanent mode
    • The tree view is always focused
  • Double-clicking a tree view entry opens the file in permanent mode
    • The editor is always focused

Thoughts?

[monsterkodi]

On 21 Mar 2016, at 17:38, Michelle Tilley notifications@github.com wrote:

Thanks for bringing up this issue again, all. @kuychaco https://github.com/kuychaco and I chatted about this last night and would love to explore some options.

To set context, the current behavior is predicated on the assumption that the thing you probably want to do with a file after opening it is edit its contents. With the changes to pending pane items that landed in Atom 1.6, both single-clicking and double-clicking a file in the tree view opens the file for editing, but now in different states (i.e. pending vs. permanent). However, it's obvious here that the goal of clicking on a file is not always to edit it, but sometimes to manipulate it in other ways. We'd like to support the best of both worlds if we can.

Here are a few things we brainstormed; we're not super set on any of them, and some of them may be terrible ideas. :P We're also open to other suggestions.

Retain the old behavior (single-click to open a file and retain tree view focus, double-click to open a file and focus the editor) if pending pane items is disabled (via core:allowPendingPaneItems). I'm particularly curious if people who would prefer the old single-click behavior of keeping focus in the tree view even use/care about pending pane items. This would be trivial to implement.
Change single- or double-clicking on a tree view file to dispatch an action instead of directly calling Workspace::open (e.g. tree-view:open-selected-file and tree-view:open-selected-file-alternate). Then a small snippet of code inside init.coffee would allow folks to re-focus the tree view easily after the single-click action has been dispatched. This provides additional flexibility as people could overwrite a lot of behavior by hooking into the command dispatch, but requires people to edit their init script to get the old behavior, and is pretty complicated overall.
Add an option for tree view along the lines of "Focus editor upon opening a file." However, as mentioned, there are now two states a pane item can be in after opening, triggered differently by single- or double-clicking, so I'm not sure if we'd need additional options there. Perhaps something like "Focus editor upon opening a file in a pending state"? (This could go hand-in-hand with option 1.)
For simplicity and flexibility, I'm personally favoring the "Focus editor upon opening a file in a pending state" option along reverting to the old behavior if pending tabs is completely disabled; in short, it means that single-clicking would always retain tree veiw focus and double-clicking would always focus the editor, no matter whether pending items are enabled or not. Then, if and only if pending items are enabled and the new option is checked, single-clicking a file will focus the editor (the current 1.6 behavior):

With pending tab items enabled:
Single-clicking a tree view entry opens the file in pending mode
With the new option enabled, the editor is focused
With the new option disabled, the tree view is focused
Double-clicking a tree view entry opens the file in permanent mode
The editor is always focused
With pending tab items disabled:
Single-clicking a tree view entry opens the file in permanent mode
The tree view is always focused
Double-clicking a tree view entry opens the file in permanent mode
The editor is always focused
Thoughts?

This sounds like a good solution to me. It should make everybody happy :)

[billyjanitsch]

@BinaryMuse thanks for the detailed follow up. 😊

To set context, the current behavior is predicated on the assumption that the thing you probably want to do with a file after opening it is edit its contents.

I think this assumption is correct, but you're further assuming that users conceptualize single-clicking a file in a list as opening it rather than selecting it, which I think is generally false (again, think of how file explorers, email clients, other text editors, etc. typically behave).

Add an option for tree view along the lines of "Focus editor upon opening a file."

That sounds great -- though I'd suggest that it be disabled by default. (The Windows file explorer has a similar option to open files on single-click, also disabled by default.)

[adamreisnz]

I'm of the opinion that if you want to edit a file, you are already going
to double click it, so when single clicking it's either to preview a file
or to perform a tree view action on it.

Following that logic, it doesn't make sense to me to focus the editor in
those cases.

So my preferred solution would be option 1, and simply to revert to how it
was. There is already a multitude of ways to focus the editor on a file,
double clicking in tree view, using the fuzzy finder, opening a file
externally, etc. So I don't see an urgent need to make effort to add a
fourth way, even if it's configurable. But if it doesn't take too much
effort and if it would make some users happy to have single click focus the
editor, then option 1+3 would be ok.

Has anyone ever asked for this feature at all?

On Tue, Mar 22, 2016, 07:25 Billy Janitsch notifications@github.com wrote:

@BinaryMuse https://github.com/BinaryMuse thanks for the detailed
follow up. [image: 😊]

To set context, the current behavior is predicated on the assumption that
the thing you probably want to do with a file after opening it is edit its
contents.

I think this assumption is correct, but you're further assuming that users
conceptualize single-clicking a file in a list as opening it rather
than selecting it, which I think is generally false (again, think of
how file explorers, email clients, etc. typically behave).

Add an option for tree view along the lines of "Focus editor upon opening
a file."

That sounds great -- though I'd suggest that it be disabled by default.
(The Windows file explorer has a similar option to open files on
single-click, also disabled by default.)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#749 (comment)