Subgroups / Folders

[jtagcat]

Is your feature request related to a problem? Please describe.
I have ended up with a huge list of groups, sorting them by what needs to be done within them would help a lot.
Describe the solution you'd like
A reference from the bookmark world: folders. 'Create new folder', then drag and drop (or move groups by some other way) to in and out of folders. Infinite nesting would be great. Clicking on a folder opens/collapses it.
Describe alternatives you've considered
Not using STG as much or not as efficiently.
Additional context
Love you for your work.

[Drive4ik]

Some users have already offered this feature. But it is very difficult to implement, and can have many problems. Many of which the browser itself can provide.
Sorry, but so far this is not possible.

[jtagcat]

Could the issue be left open?

[Drive4ik]

Ok
duplicate of #302

[jtagcat]

But it is very difficult to implement, and can have many problems.

Did you mean changing the architecture?

I thought of this more visually: the sidebar/click on add-on: you currently have groups.
In the json, a field 'displaylocation' could be added for each group. When the sidebar is listing groups:

• group foo and bar with both displaylocation: "honk" will be at /honk/foo (open 'folder' honk, foo and bar are displayed)
• (advanced, doesn't necessarily need implementing) group baz with displaylocation: "honk/bonk" will be at /honk/bonk/baz (open 'folder' honk, where there's groups foo, bar, and a folder bonk, opening bonk displays baz)

Architecturally, of tab/group management, nothing needs to be changed. Though I understand if the thing rendering the sidebar is hardcoded to groups.

This feature request is because my workaround for many tabs in one group is getting out of hand: Instead of having 350-400 tabs in one group, for performance reasons, they are currently in 18 groups, 17 of them archived for performance reasons.

In addition, I have category divider groups (empty group with *******NAME******** and a noticeable icon). Instead, moving categories to folders would also help in finding things.

Having 5 pages worth of groups to scroll isn't great as: I'm searching for the right thing too long (search is often very slow, even if I want to only search for group names more often than not); creating a new group and dragging it to the right place is slow as well.

Having a workaround for my workaround, maybe changing the zoom level & adding 2nd column for the side bar would help (or just a manage groups page without tabs displayed).

I'm asking for workaround workaround workarounds, I'm quite frankly out of my mind, pardon.

[grahamperrin]

… I'm asking for workaround …

… 5 pages worth of groups … (search …

Tab Manager Plus

From #705 (comment):

• the vertical view mode of Tab Manager Plus

– this is one of a few extensions that can offer a full-window overview of all tabs. Ideal for switching from one tab to another, and so on. Excellent performance, where a session has many tabs (I have 1,404 at the time of writing).

Here's a different mode – block view – in the window to the right:

• there's another screenshot under Tab group label alongside navigation bar button #319 (comment)
• and so on.

[nkakouros]

@Drive4ik What if there was just a simple tags feature where each group could have one or more tags? In the modal window that opens after clicking the toolbar icon, there could be a setting to either show the list of groups (as is being done now) or to show tags and inside each tag the matching groups. In the dedicated manage groups page, there could be a dropdown (or a sidebar) to select the tags that the user wants to show (more specifically, the groups matching the tags).

[jtagcat]

displaylocation: "honk/bonk" pretty much already is tags.

You'd need a 'no tags' group as well, and account one tab may have multiple tags. Building a separate view for tags doesn't seem resourceful.

[kauesena]

I like all the suggestions mentioned. I don't see the need for subgroups to be as robust as groups. Any visual indication that a certain set of tabs withing a group is related would already be very useful. If in a group I am researching more then on topic, it would be nice to discern the tabs relating to topic A from those relating to topic B.

[peterwx]

I'm also of the opinion of using tags like @nkakouros said, but only for filtering on the manage groups view.
The tags could for example be present on a dropdown or on one of the sides of this view.
Selecting one would present only the groups with the selected tag.

To me, it doesn't make sense to have more than a tag per group because among other things I use another extension together with STG. And one would be only wanting to focus on a group at a time.

@Elon61, @GonzRon, @jdevoldere, @kauesena, @mtnjustme, @Stetto, by your previous issues and issue comments I think you'll be interested in the following text and I'll be interested to see if something is flawed, missing or there is partial or general agreement. I've presented a detailed vision of tab/window/project/task/workflow management with a combination of 2 existing addons that I believe with certain improvements can go from almost to very close to 100% fulfilling our needs (I've been using those addons for many years) here and very short post precursors that omits many details there and there (all links point to connect.mozilla.org - the official site for Mozilla's Firefox feedback). In short, adding to an improved STG(group tags) features from the other addon(sidebar collapsible "tasks").

Elaborating a bit more on how feasible adding those features IMO would be:
Adding a tag to a group doesn't seem complicated as isn't also having "folders"/"tasks" on the sidebar. "Tasks"/"folders" as imagined and tried with the aid of 2nd addon "Tab Sidebar" relies on "marker" tabs that can be named and are created by the user to fold and unfold the tabs below it until the next marker tab or the end of tabs/current group(I've written custom CSS for TS for when TS was applying markers to hidden tabs that didn't belong to the current STG group or showing those hidden tabs - and also I was counting tabs for each marker/group with CSS, so I needed this).
Such folding and unfolding can be easily applied with CSS and CSS classes.
So this 2nd part("tasks"/"folders") doesn't seem to require much logic at all - tab state is handled by Firefox's remember session mechanism(which includes remembering TS "marker" tabs) and STG handles group state and tab hiding. However TS source code seems not to be available with the exception that one can view it with the Extension viewer addon that extracts source from AMO store or one could unzip the locally installed addon .xpi. Tree Tabs (not Tree Style Tabs) implements both groups and folders(but not tagging) and its source is available in gitlab- I've described Tree Tabs shortcomings on another issue comment below.

I imagine STG could add another switchable view on the sidebar that could reuse some of the code for displaying groups but repurposed to only show current group with its tabs and "marker" tabs. Or as an option to the existing group view, replacing it, since groups can be managed in the "Manage Groups" view. Nevertheless a group select dropdown could be present on the sidebar for easy access to select the desired current group(maybe even prepending a tag would show only those tag specific groups for selection).

I think I'll be creating at least a new issue for the suggestions in that link(that I think would cover once and for all most user's tab management dilemmas related to a tab/window/project workflow organization enhancing and optimizing perspective - if implemented). But maybe not, then it would be potentially considered a duplicate. I will be adding my feedback in this issue first and see how the issue evolves.

PS: Meaning clarification/Glossary - if something is not as clear as it should be please say so.
"Task" - a named unit where tabs are placed by the user, those being related by a common end goal to be accomplished at some (later) time from now. In the same unit, one can have for example tabs whose URL's can be of distinct domains like tabs for search, for tools, referencing, collaboration, buying, etc.
In the browser UI, it's located on Tab bar(ex: chromium-like groups) or Sidebar(vertical tabs mode).

[GonzRon]

thanks for the tag, it's been a long time since I wrote #302 , can't believe no modern browser has addressed workflow optimization. Most browsers haven't evolved in this respect since Netscape. Sure you can open tabs, and now use containers, but bookmarks don't cut it. Users want a more dynamic / nuanced approach to browsers since so much nowadays is happening on the web. I feel in part that this is due to the commercialization of the internet and the underlying dynamics of consumerism and capitalism driven advances in tech. The internet was supposed to be empowering to the individual for research, but what we have today is more about commerce. Hopefully we can advance the state of the art, (e.g. ideas like this) in, (just as an example), Gemini Protocol browsers. Modern browsers are full of bloat and adding groundbreaking tech like the ideas we're discussing here is apparently too hard. However Gemini protocol browsers are still very simple, and you can likely build in features like #302 into those browsers much more easily.

P.S.
The author of this plugin deserves recognition for being way ahead of his time and actually implementing the ideas and concepts of tab organization. The project location is seemingly Ukraine, and we all understand what's happening there now. So the maintainer has seemingly not been around to commit much code. It's high time for a modern browser to tackle this issue. I disagree with the original maintainer in his comments that this would be too difficult for most end users to understand. Hierarchical Tab Containers, nested groups, etc. is functionality that is unobtrusive, i.e. it's there if you want to use it, but doesn't get in your way if you can't be bothered with it,.

[peterwx]

Hope @Drive4ik is alive and well.
I believe there are people to take on this project if necessary.

In my view, I tend to agree with the author, because some issue proposals would be in principle of high algorithmic and performance/design bug/complexity/development cost(In mine I do away with nesting without compromising, I believe, on the end goals of the other proposals).
Yet I believe that such proposals can be achieved practically if approached from an angle similar to what I proposed in the mentioned link in my previous post. In fact, that what is proposed are improvements to existing addons, that I'm convinced would be totally feasible in Firefox with tags and no nesting would be in principle necessary to fulfill workflow needs.

If some features would not be understandable, that would be OK, they would be an OPTION for users that want them, understand and make use of/enable them.

[peterwx]

A kind of inferior workflow alternative to what I've linked is the Tree Tabs addon (not to be confused with TreeStyleTabs) that offers groups and folders inside groups. However, nobody knows of the original maintainer and the addon is somewhat problematic for managing groups - the groups (titles) are all displayed vertically (text baseline is rotated 90º anti-clockwise) making them not so comfortably to read and if having many groups, one is forced to scroll through those many vertical groups to reach desired one, especially if the task involved is to reorder groups to later be able to select/switch to the most important ones easily.
The catching of tabs by patterns into groups isn't working and group tagging is non-existing feature.
And it mixes managing groups with operations inside groups, when at most selecting the current group from a dropdown and/or search (not an accordion) should be present in the sidebar. So in my opinion the vertical strip should be taken away to a view like that of STG's "manage groups" or if not taken away, be activated in a button/"fake" tab in the sidebar that would only show a view of groups. The main sidebar view would be only for a single selected current group and its folders. This would make TT less cluttered, more "understandable" and manageable/usable.

But I think if you(@GonzRon) and others experiment with this addon the workflow that I described on Mozillas's Connect in mind, you'll understand its point and usefulness, before trying the main combination.