piroor
commented
5 months ago 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.
SHHSSH
Hi @piroor
I am looking to request a feature where if the user Shift+Clicks on a tree that is currently expanded that all sub Tabs/Trees are selected as they are if the tree is collapsed.
I'm currently using macros to Shift+Click+Application Menu Key(the key we discussed a few months back) on the current active tab through image recognition. This allows me to quickly access the context menu for multiple tabs and easily unload them or whatever need be done.
Unfortunately for trees that are expanded this does not function as I think it should.
To clarify once again, when a tree is expanded, if the user Shift+Clicks on the tree parent, TST does not select the sub trees/tabs as it does when the tree is collapsed.
I don't believe there are any TST settings that adjust this but if you need to confirm any settings that you think might be relevant please run your thoughts by me.
Thanks.