atom/tree-view

Discussion: Manipulating squashed directories

winstliu opened this issue · 3 comments

winstliu commented

This is an issue that is meant to spark some discussion and (hopefully) come to a conclusion regarding the expected behavior when copy/pasting or drag/dropping squashed directories.

Currently

  • Copy/pasting a squashed directory only copy/pastes the final directory in the chain (given a squashed directory path dir1/dir2/dir3, only dir3 will be copy/pasted when selecting the squashed path).
  • Drag/dropping a squashed directory moves only the final directory in the chain but does not update the visual appearance of the squashed directory (it continues to appear as dir1/dir2/dir3). Attempting to drag-and-drop this squashed directory again results in an error being logged to console (ENOENT about the directory path not being found, as the last directory has been moved). Collapsing and re-expanding the parent directory updates the visual appearance.

Proposals

  1. When manipulating squashed directories, copy/move only the last directory.
    • Benefits:
      • Each directory can be individually manipulated, albeit with some Tower-of-Hanoi-ing (from @lee-dohm).
      • Directory manipulation is consistent in the sense that the last folder is always moved.
    • Downsides:
      • The operation does not line up visually with what is selected.
  2. When manipulating squashed directories, copy/move the entire squashed directory structure.
    • Benefits:
      • Directory manipulation is consistent in the sense that the operation will line up visually with what is selected.
    • Downsides:
      • There is no way to manipulate any of the intermediate directories.
  3. When selecting squashed directories, unsquash them.
    • Benefits:
      • Each directory can be individually manipulated and it is always clear what directory is being targeted.
    • Downsides:
      • Changes the visual appearance of the Tree View when a squashed directory is selected.
lee-dohm commented

I consulted with one of our designers on this and they felt that:

  • Option 3 is probably the most optimal because it allows the user to select what they want
  • Option 1 is a decent fallback if option 3 is too much of a technical lift
  • Option 2 will probably cause problems even if selecting the least nested node is the common case
  • 👍2
lee-dohm commented

Thanks for opening this discussion @50Wliu 🙇

We reviewed this in our weekly triage meeting and had some questions (assuming that you're intending to implement this functionality):

  1. Do you believe that Option 3 is something that you'll be able to do?
  2. If not, what is the current behavior without any of the above proposed changes?

Thanks!

winstliu commented

I haven't investigated if option 3 is feasible. The current behavior is listed at the top of the issue.