search

coteditor / CotEditor

Lightweight Plain-Text Editor for macOS
https://coteditor.com
Other
6.46k stars 431 forks source link

"Show in Finder" resets the sidebar state #1689

Closed kishikawakatsumi closed 2 months ago

kishikawakatsumi commented 2 months ago

Description

If some directories are expanded in the sidebar, use "Show in Finder" to show the files in the Finder. Then the state of the sidebar is reset. It seems that this event is triggered by manipulating the directories displayed in the sidebar with the Finder, Probably “Show in Finder” is not directly related to this issue.

To Reproduce

  1. Open a folder.
  2. Expand some directories.
  3. Run “Show in Finder” on any of the files.
  4. The sidebar state is reset. (If the problem does not reproduce, try opening the directory in Finder)

https://github.com/user-attachments/assets/fd50e28d-f0f9-445a-a216-40a5f20b8383

Expected behavior

The expand/collapse state of the sidebar is kept even if the directory opened in CotEditor is manipulated from the Finder.

On the other hand, file changes should be updated.

CotEditor version

5.0.0-beta (661)

macOS version

14.6.1 (23G93)

Additional context

No response

1024jp commented 2 months ago

Thank you for the report. However, it doesn't happen in my environment... Let me have time to investigate.

kishikawakatsumi commented 2 months ago

The direct cause is that when you open and close a directory in Finder, the DirectoryDocument's presentedSubitemDidChange(at:) method is called, and as a result, the FileNode's invalidateChildren(at:) function is called.

The url argument of presentedSubitemDidChange(at:) points to the .DS_Store file. (It seems that the .DS_Store file is updated when the directory is opened and closed in the Finder.)

As a result, all the references to the child elements are replaced, and the outline view loses its open/closed state.

This problem does not occur in Sequoia. It seems that Sequoia's Outline view has been changed to use Equatable to determine equivalence rather than reference matching (confirmed).

Also, I was mistaken, but it seems that in Sonoma, if the element is a struct, Equatable is used to determine equivalence. However, I have only checked for simple cases using structs, so there is a possibility that other problems may occur.

In the case of CotEditor, the problem may be solved if the FileNode can be changed to a struct.

kishikawakatsumi commented 2 months ago

Alternatively, you could use invalidateChildren(at:) to update the delta instead of replacing all, but that would probably increase the complexity dramatically.

1024jp commented 2 months ago

Thank you for the insight. I succeed in reproducing the issue on macOS 14.

For a quick but reasonable fix, I've changed just to ignore .DS_Store files 88b89ae63c436e3149aeef9672ac98c3cc23b9fb. (As I decided to ignore .DS_Store files for the file browser.)

Alternatively, you could use invalidateChildren(at:) to update the delta instead of replacing all, but that would probably increase the complexity dramatically.

Yeah, it's way too complex for me. Since the issue seems to be fixed in macOS 15, I'll try to fix what can be fixed while allowing for some of the unnatural behavior in macOS 14.

kishikawakatsumi commented 2 months ago

It's probably the same problem. When I move files in the tree view, the state resets (this doesn't happen with every file move, and it seems to happen more often when the root directory is included). This is probably inconvenient for normal use.

https://github.com/user-attachments/assets/97f042c9-51db-46c3-9225-560100041e6e

To Reproduce

  1. Open a folder.
  2. Expand some directories.
  3. Drag & Drop any files to other folder in the tree.

Expected behavior

The state of the tree view remains the same as it was before drag & drop.

CotEditor version

5.0.0-beta.2 (663)

macOS version

14.6.1 (23G93)

1024jp commented 2 months ago

I took several measures in order to reduce closing folders needlessly. I guess it's still not perfect, but I suppose this is as far as I can go.