[Feature request] (Sub Tabs/Trees selection Shift+Click is pressed) about treestyletab HOT 2 CLOSED

In short: I'm negative to implement this as a built-in option. TST's special behavior on a collapsed tree + shift-click is based on the policy to keep consistency.

Shift-click on a tab is an action to highlight tabs between the clicked tab and the previously clicked or the active tab.
Assume that there are some tabs:

• [A]
• [B]
• [C] (Active)
  • [C-1]
  • [C-2]

On this case,

• When the tree "C" is expanded, Shift-click on "A" will highlight the clicked "A", the active "C" and all their between tabs, so it will highlight only "A", "B" and "C". This is natural from their visibility.
• However, when the tree "C" is collapsed, Shift-click on "A" will highlight "A", "B", "C", "C-1" and "C-2". This is because to prevent "C-1" and "C-2" are left there after you move highlighted tabs to another place.
  • Shift-click on "B" will highlight "B", "C", "C-1" and "C-2", from same reason.
  • So, how we should treat Shift-click on "C"? Currently it is treated as "the clicked C, the active C, all tabs between them, and C's collapsed children". Why?

TST's this kind behaviors refer the one on other UIs in Firefox and other major applications. The basic strategy of Shift-click on this case refers item selection on Firefox's "Browsing Library" and Windows Explorer.

• On "Browsing Library", a list may contain both bookmark items and bookmark folders. When you drag multiselected items including bookmark items and folders and drop them to another folder, all dragged items and folders are moved under the drop target, and of course descendants of moved folders are still descendants of the moved folders - they won't be left under the original folder dragged folders were in. So, I think the current behavior - descendants are also moved if a moved tab has collapsed descendants - is similar the one of the Browsing Library and reasonable.
• Another case, the "list view" of macOS's Finder is also similar to these UI. On Finder, shift-click on a folder just highlights the clicked folder (and items between the active item) but children of the clicked folder won't be highlighted whether the folder is expanded or collapsed on the view. This selection behavior is similar to TST's one about the expanded tree case.
  • Drag-and-drop of them will move them and their descendants also. This is not similar to TST does.
  • But setting color label from the context menu just applies chosen label for highlighted items and folders - descendants are kept color label free. This is similar to TST does.

We need to remind that TST's (Frefox's) tabs are different from items and folders on these cases. TST's tab behaves like both folder and item. It needs to be moved individually like told at #3538, so simulating the behavior of macOS's Finder completely (move descendants together even if only the parent is highlighted) looks not suitable.

However any helper addon providing the behavior (shift-click on an expanded tree parent to select all its descendants) is always welcome. I'll add it to the list of known helper addons if you publish it.

from treestyletab.

Thanks for the explanation, I'll look into developing a solution.

EDIT A personal reminder to acknowledge the potential importance/utilisation of unfocused TST sidebar prior to Shift click to remediate issues with previous focused/selected tab.

from treestyletab.