Support TreeStyleTab

[hjri]

Is your feature request related to a problem? Please describe. I'm using tab manager in conjunction with TST https://github.com/piroor/treestyletab and it mostly works, but there are still issues. I mostly use Tab manager to manage tabs across many windows, so support for it would be much appreciate it

Describe the solution you'd like At the very least: Displaying tab hierarchy Able to edit tab hierarchy would be the best

Describe alternatives you've considered No alternatives, just living with it or without it.

Additional context TST provides API https://github.com/piroor/treestyletab/wiki/API-for-other-addons

[xcv58]

Hi @hjri I haven't used TST before. I just install it on FireFox and play it with a few mins.

It seems the hierarchy is maintained manually by the user. If yes, it's possible to support it in this extension. Could you please tell me more about the "hierarchy" you mentioned? I want to cover all use cases before implementing it.

Thanks for sharing your idea!

[hjri]

I mean the tabs are represented as a tree instead of a list. I think internally it's still a list since i get occasional glitches where there are tabs seemingly out of place (i.e. there's a tab inside a "branch" but it's not part of it).

Hierarchy is completely user-controllable, but TST gives a lot of options on how to manage trees automatically, i.e. what to do when you press "Open new tab" - should it be a child of current tab, a sibling, a new independent (i.e. root) tab, what to do when you click links that open in new tab, etc. It also gives shortcuts for closing/reloading entire branches/siblings and other convenience options.

I think the most common use case and case intended by author is "tree represent browsing history", where you open links mostly in new tabs and see the history as trees. Like opening multiple bugs from issue tracker, and in some issue opening a merge request page, and from that merge request page you open a link to documentation and so on.

At work however i use 3 windows across several monitors and workspaces and sometimes i end up opening some stuff in wrong window and want to move it to another, especially like aforementioned "open up several issues" case. "Group all domains to this window" helps a lot but it seems it doesn't work well with TST, would be nice to group them under a dummy tab or just make them independent when moving, as well as allowing same-ish level of control over tree hierarhy when moving - i.e. be able to detach a child tree from one parent and reattach it to another parent in a different window, move entire branches between windows.

[xcv58]

Thanks for sharing your thoughts!

I mean the tabs are represented as a tree instead of a list. I think internally it's still a list since i get occasional glitches where there are tabs seemingly out of place (i.e. there's a tab inside a "branch" but it's not part of it).

Do you mean just represent the tabs and windows in a tree-like view, without group tabs by some criteria? Does something like this work https://codesandbox.io/s/62wj7?

Hierarchy is completely user-controllable, but TST gives a lot of options on how to manage trees automatically, i.e. what to do when you press "Open new tab" - should it be a child of current tab, a sibling, a new independent (i.e. root) tab, what to do when you click links that open in new tab, etc. It also gives shortcuts for closing/reloading entire branches/siblings and other convenience options.

I think the most common use case and case intended by author is "tree represent browsing history", where you open links mostly in new tabs and see the history as trees. Like opening multiple bugs from issue tracker, and in some issue opening a merge request page, and from that merge request page you open a link to documentation and so on.

I think all these are focusing on managing the tabs by introducing groups/hierarchy that are not the data provided by the browsers. I do think those features are useful and can improve productivity a lot. But I'd prefer to use something the browser natively supports like #287 instead of inventing a new thing.