killer feature
the only one reason why i use firefox

👍 this 👍

Today I learned that, while I sometimes think I have many tabs open, there are perhaps people with many, many more.

@The-Compiler is it hard to implement tree style tabs? will you do it?

is it hard to implement tree style tabs?

Hard to say - the basics of indenting pages should be relatively easy, but then there are other things like collapsing/expanding, handling the tree in sessions, etc.

will you do it?

Will you? 😉

I will at some point, but I don't need this functionality myself and I have other priorities right now - so it'll likely take a few months until I get to it.

Just giving my +1 to this; I typically browse to research something, and it's not uncommon for me to have 100+ tabs open, all neatly organized in trees so I don't have to remember why I opened such or such tab.
Even just indenting the child tabs (without advanced options such as folding a tree or options for how should child tabs behave when parent is closed) would go a long way into providing more structure when having a lot of tabs open.

An (ugly, but functional) alternative would be to assign a random color to all tabs that are from the same parent. There's a FFx addon that does that too; assign a random color to all parent tabs then assign an increasingly lighter color for child tabs (so, parent tab, dark blue, child tab, lighter blue, child of child, even lighter blue).

I'd just like to leave a support +1 for this feature. It's become almost mandatory for me to have tree-style tabs at this point since I started using it with Firefox. I'd like to transition to qute but this feature would be sorely missed.

Would this be something that would be possible to write using the current userscript system? I'd be interested in trying, but don't know where to start.

@sitonapanotis You posted your comment ~25 times, I deleted the others now - if you have a customized user agent, you'll need to set it back to the default for GitHub to work correctly 😉

It's not possible to implement this via an userscript, no. I'm not sure how much effort it'd be to implement in qutebrowser's core (i.e., in Python).

There are already vertical tabs, and from what I've gathered here the main feature people are missing is the indenting of related tabs, correct? I think that should be relatively straightforward to implement for someone knowing a bit of Python. If someone wants to step up, I'm happy to help.

@The-Compiler sorry about that, I was using a chrome user agent to make inbox.google.com work, changed back now. I'll have a look at the code and start trying to figure out whether this is something I can realistically work on.

Some pointers:

• New tabs are opened in def tabopen in mainwindow/tabbedbrowser.py - that already has an explicit argument set to True if it's a new "group", or False if it was opened from another tab.
• You'd need to store whether a tab was opened explicitly somewhere in the tab, for example as tab.data.explicit (see TabData in browser/browsertab.py). Though probably you even need to know what page it was opened from?
• Then the tabbar in mainwindow/tabwidget.py should somehow get and handle that information correctly.

I'm not sure what would happen when you move an indented tab to a new position, or probably some other corner cases like that... I guess the affected tab would lose their indent then?

Behavior in TreeStyleTabs (for reference):

DnD:

• If a tab is dropped on another tab, it becomes a child of the tab (indent of the tab it was dropped on +1)
• If a tab is dropped between two tabs that have same indent, it takes the same indent
• There are two drop areas between tabs of different indent, one for each indent

When a tab with children is closed, behavior is either (depending on user options):

• promote the first child to the indent of the closed tab (confusing imho, but faster for some reason on my PC)
• Promote all children tabs to the indent of the closed tab
• Close children tabs
• Detach children tabs from tree (indent 0)
• Create a dummy tab in place of the closed tab

Opening a link in a new tab:

• Becomes a child of the tab

Creating a tab (depends on how it's opened):

• Ctrl-T or click on "+": Indent 0 at the bottom of the tree
• shift-ctrl-T or shift-click on "+": As a child of the current tab

A simplified version for QB could be to:

• Give each tab an "indent" property that can be manipulated by the user (e.g, ctrl-left/ctrl-right to increase/decrease the indent).
• Allow any tab to be indented up to "indent of previous tab +1" but no more
• Allow any tab to be intended down to 0 but no less
• When increasing or decreasing the indent of a tab, cycle through all "next tabs" that have a higher indent than the current tab and reduce or increase their indent by 1
• When closing a tab, cycle through all next tabs that have a higher indent and reduce their indent by 1
• All links should be "indent of the origin tab +1"
• When moving a tab, it should adopt the indent of the surrounding tabs if it is similar, or the lowest indent if it is not.

I think this would cover all the bases with just one added property, no messing about with groups and drop targets and what not.

I haven't thought lengthily about this nor have I ever implemented anything similar, but I think it could work.

As a matter of fact, I'd be ok with just an "indent" property that I must manipulate myself, as long as I can do it for multiple tabs at a time. It would be sufficient to differentiate tabs visually.

@Xananax Thanks for the great overview! This definitely seems less simple to get correct than I initially thought 😉

#1788 helps TST usage / idea, methinks

"(tabAttach) also comes in handy when skimming while researching for reading later. It is quite common for the user to, when interested in a given subject (like "mmmm, ¿should I move from Vimperator to this new QB novel?"), jump to opening dozens of pages on the matter with the help of google (and from those open another dozen of links), only to skim the general info and possibly save part of them for in-depth info later. With tabAttach one can easily move pages between a window for "input", another for "done deal" and a third one for "read thoroughly later" "

Could you rephrase "greatly informs TST usage / idea"? I don't understand what you're trying to say with that.

I guess it's a pompous way of saying "it helps the functionality that TST brings / promotes", in the sense that, if one is going to expect tabs nested in a hierachical tree, moving those trees and / or tabs between windows comes in handy.

Not sure if I should open another feature request for this, but a different way of implementing a similar functionality (for me, at least), is to implement the same thing as Firefox workspaces: named groups of tabs.

I use tree style tabs to switch contexts; example: I'm answering emails, and I remember I need to check this new framework. I do a google search for it in a new tab and open a few articles, then collapse the mother tab to get those out of the way. Later, at lunch, I'll come back to those, deepen my research, then collapse all again to get back to work; etc. Some of my collapsed tabs sleep for weeks, until I get back to them (I always do).

Any way of grouping tabs together, hide them and recall them (without reloading) would work for me.

Since I feel the basic need can be fulfilled by either tree style tabs or groups, I'm not opening a new issue, but I'm not sure if that's the only thing people use tree style tabs for.

Yea I agree they're kinda different, but there's overlap. It's just, any way to organize tabs as related (even something as simple as just assigning colors) would instantly make QB much more useful to me, so I'm throwing out there all the possibilities in case something is easier to implement than tree style tabs.

I agree that this may warrant a different feature request, but in my personal case, I wouldn't care much for groups if there was a tree.

Xananax: Overlap or no, that is a different feature. Your last sentence makes that perfectly clear!

By the way, Tree Style Tabs is what has me stuck on Firefox though I would have left years ago it any other browser supported it. Of course, the only other thing that Firefox has going for it is Vimperator, so once this feature is implemented I'll be the first to start using and promoting qutebrowser.

Thanks.

Another example of a browser with Tree Style Tabs is https://github.com/kovidgoyal/vise

It is also written in python, so perhaps could draw some inspiration.

Note that the afore-mentioned Vise is developed by the same person who develops the excellent Calibre ebook manager.

However he considers Vice to be a hobby, not for public consumption. It would be nice to take the tree view from Vice into qutebrowser.

[1] https://calibre-ebook.com/

Just wanted to mention that I'm toying with this feature in qutebrowser. I'm really missing tree tabs from firefox so I somehow managed to get them in qutebrowser :-)

Code is horrible right now (I'm not used to python and object oriented code anymore) and it is quite buggy for now. However here is screencast how it is working right now :-)

Any comments and ideas are welcome.

@vlcek that's awesome news, you should make it public, so those who interested could help you.

OH. MY. GOD.

I think I'm not the only person who'll actually donate you for releasing & finishing this feature.

@vlcek I would be willing to help with testing/developing this as well, in the interest of trying to get this 'usable' before Firefox deprecates their plugin system (which breaks the tree style tabs plugin). If you could publish what you have in a fork that would be awesome :).

Firefox 57 (the first one to deprecate such addons) is scheduled to release in November.

@Vicek That's amazing.

I would like to pinpoint one of the features (or maybe it's an accidental feature) of TST that I'm keen on:
the specific "about" url that accepts any string and renders a "nice-enough" looking page. (Sorry if this is obvious to all TST fans, but I never read elsewhere anybody describing this particular goodie). The folllowing:

about:treestyletab-group?

can be used as "divider" between many tabs and/or an customizable "marker/freezer" of any page.

In other words, imagine that in a initial moment of a given research one opens several windows with many tabs each to be read and compared. As the user progresses in reading / research, he/she can close/pin a tab by opening :

about:treestyletab-group? ‹‹ Done Deal

or

about:treestyletab-group? Good analisys on foo (lacking on bar)

or even, as a divider :

about:treestyletab-group? ⇣ these here great ⇡ these here not quite

...Resulting in a visual annotation of the work that preserves everything (as the user can always go back in history on each "about:")

This is also a neat way of canceling heavy pages to preserve the browser responsiveness, as a proccessing offending page (I'm looking at you, Facebook!) can be nicely "masked" under an open: about:treestyletab-group? ‹‹ READ LATER which, incidentally, can be mapped to any keystroke under the vimperator/qutebrowser/vimish logic.

(I avoided to burden this thread with such prolixic description in the past because "about:" in qutebrowser was working just the same, preserving history and all. But at some point that ceased to be and now with @Vicek 's contribution I thought that it would be a good point to present the case for such functionality.)

(an example of a session of mine:

)

Oh, I didn't know that they are planning to deprecate it so soon. I consider it just as a proof of concept and a toy project of mine.

Some comments to the code I have now:

Tree tabs are hardcoded (there no options to turn them off) and there is actually no support for tabs history. I am using tree data strucutre (anytree package) for storing tree tab structure. I have modified tab title update function to reflect the shape of the tree structure. Therefore all modifications of the tree are reflected in tabs as a title change.

I will release the code in brach after I make some comments. I hope it won't take long :)

#3943 also has some thoughts of it with some alternative proposals, though I'm not sure how well those would work out in practice.

( @vlcek @kepi @Yodzorah)

I've just noticed a possibility of a hack days ago that, although marginally related to this thread, could add / contribute to the general list of ideas on hierarchy of tabs and organizing.

(sorry if I derail the thread, but I thought that users keen to the TST feature could really benefit from this little thingy)

The hack would be :

:buffer =

99% of search engines use the char "=" in their urls. And as an user starts opening and searching in tabs and windows, those search result pages become cornerstones of the research output, main anchors of reference in a fast growing "mess of tabs".

So, if ones maps whatever keybind to ":buffer = " , one can have an instantaneous list of ALL search result pages, across all windows, ready to check or navigate to. All that in a simple key press.

Again, sorry for derailing the thread (but I'm genuinely excited for this little find).

But, on another hand, the concept could be polished into the TST logic, like an "automatically make any search result page a parent node"; or "list all search 'results' trees'", etc

Is the development on this feature considered halted at this point? Are we looking for someone to contribute and remove the anytree dependency?

@HeathNaylor looks like that

Pretty much that, yeah (though the current bottleneck is mostly reviewing contributions). But as usual, as long as nobody picks things up, it won't get done 😉

Hi, I currently have a lot of free time on my hands, and I'd love to see this feature come to life again. I want to contribute! Where should I start?

All right, tank you for the pointers. I'm particularly interested in this feature, so I'll mainly work on this; but seeing that there's such a problem reviewing PRs, I'll be happy to check some of them out as well.

Okay, I got it to work with the current version, and I removed the anytree dependency!
Before it can be made into a proper pull request, I still need to add docs, more tests, and a few essential features, but it works well enough that I'm using it in my main browser.

Meanwhile feel free to check it out on my fork!

@Yodzorah, in principle I want this feature to be as complete as possible, so I'm happy to talk about additional features like this one.

I've read #3943 . From my understanding, the difference between your proposal and firefox-like Tree Style Tabs is that here there's two kind of relationships: parent->children (hierarchical), and children->"other connected tab/idea" (non-hierarchical). It shouldn't be too hard to implement this second kind of connection in the underlying tree data structure, but I'm not sure how to clearly show the relationship graphically - the current implementation shows tabs with a very simple textual tree (like the one you get running tree on unix). The ASCII-drawn example on your issue shows the connection clearly, but I don't think it's feasible because it would need too much horizontal space (tab/idea names are often more than one word long). We need something else. Perhaps color- or symbol-coded connections (something like Firefox's containers, but without isolation of cookies etc)? Additional lines connecting "connected tabs/ideas"?

Plus, I'm not sure about the overall usefulness of this feature. I think one could achieve a very similar workflow using tree-tabs + tree-tabs-groups (mentioned above), that would allow you to have both automatic parent-children relationships and user-made arbitrary groupings.

I definitely need more input on this before I can think about implementing anything

FWIW I'd prefer to get a simple/straightforward tab tree feature in first, and then iterate on that. Contributions which are as small/simple as possible are much easier to review, and (missing) review bandwidth for contributions is a quite big issue currently.

Makes sense. I agree that this should be kept small.

Right now I'm working on adding the following features, which I believe are essential:

• integration with session-manager (right now saving sessions is messy)
• recursively closing tree-tabs
• ability to open tabs directly under tree root
• tree-manipulation commands (and keybindings) — so users can organize the tree
• adding manual groups (as mentioned above regarding FF's treestyletabs-group)
• folding trees (if implementation is easy)

Right now the codebase is still very small/simple, but we're still at the "proof of concept" stage. I don't think it would be worth merging it without these features at least. I'll still try to keep the code as simple as possible.

IMHO all mentioned seams essential. I'll be glad to test and provide feedback.

One feature/issue which I would like in initial version is create new tab on root level. In first concept presented here that wasn't possible, tab was always created under currently focused one.

@kepi: I just implemented this. Now un-related tabs (i.e. not created by following hints or :open --related -t) are created under the root node. It only took one line of code!

Quick update: all the main features have been implemented for a couple days. The code is almost ready for merging. All it's left is to add some tests and possibly clean the code a little bit.

I'd love some feedback and testing.

@pinusc let us know when/if you need testing

Well, I think we reached feature completion, so now it's the time to do some thorough testing.

I'm using the feature for my everyday browsing, so it's definitely stable enough, but there might be some bug I didn't find yet — perhaps with tree manipulation commands, or with the memoization, or session saving.

If anyone is interested in testing this, just pull my branch and use it; I'd appreciate it a lot. Perhaps feed it some weird commands, move trees around, hunt for some edge case. Standard testing stuff.

Very nice!

Some testing:

• Something broke recently, running 6eb2ee6 crashes at startup (e5e1c9c doesn't have the issue):

DEBUG    modes      tabbedbrowser:on_current_changed:744 Mode after tab change: normal (mode_on_change = normal)
DEBUG    webview    webview:render_widget:81 Found possibly lost focusProxy: []
ERROR    misc       crashsignal:exception_hook:214 Uncaught exception
Traceback (most recent call last):
  File "/usr/bin/qutebrowser", line 11, in <module>
    load_entry_point('qutebrowser==1.5.2', 'gui_scripts', 'qutebrowser')()
  File "/usr/lib/python3.7/site-packages/qutebrowser/qutebrowser.py", line 194, in main
    return app.run(args)
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 143, in run
    init(args, crash_handler)
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 185, in init
    _process_args(args)
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 226, in _process_args
    _open_startpage()
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 351, in _open_startpage
    tabbed_browser.tabopen(url)
  File "/usr/lib/python3.7/site-packages/qutebrowser/mainwindow/tabbedbrowser.py", line 512, in tabopen
    self.widget.insertTab(idx, tab, "")
  File "/usr/lib/python3.7/site-packages/qutebrowser/mainwindow/tabwidget.py", line 369, in insertTab
    new_node.parent = self.tree_root
  File "/usr/lib/python3.7/site-packages/qutebrowser/misc/notree.py", line 118, in parent
    value.__add_child(self)
AttributeError: 'Node' object has no attribute '_Node__add_child'

• tree-tab-bubble crashes if there are no siblings, for example, just run tree-tab-bubble up with only one tab open:

ERROR: Uncaught exception
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 929, in eventFilter
    return handler(event)
  File "/usr/lib/python3.7/site-packages/qutebrowser/app.py", line 902, in _handle_key_event
    return man.handle_event(event)
  File "/usr/lib/python3.7/site-packages/qutebrowser/keyinput/modeman.py", line 353, in handle_event
    return handler(event)
  File "/usr/lib/python3.7/site-packages/qutebrowser/keyinput/modeman.py", line 173, in _handle_keypress
    match = parser.handle(event, dry_run=dry_run)
  File "/usr/lib/python3.7/site-packages/qutebrowser/keyinput/modeparsers.py", line 99, in handle
    match = super().handle(e, dry_run=dry_run)
  File "/usr/lib/python3.7/site-packages/qutebrowser/keyinput/basekeyparser.py", line 203, in handle
    self.execute(binding, count)
  File "/usr/lib/python3.7/site-packages/qutebrowser/keyinput/modeparsers.py", line 56, in execute
    self._commandrunner.run(cmdstr, count)
  File "/usr/lib/python3.7/site-packages/qutebrowser/commands/runners.py", line 308, in run
    result.cmd.run(self._win_id, args, count=count)
  File "/usr/lib/python3.7/site-packages/qutebrowser/commands/command.py", line 550, in run
    self.handler(*posargs, **kwargs)
  File "/usr/lib/python3.7/site-packages/qutebrowser/browser/commands.py", line 1803, in tree_tab_bubble
    siblings.insert(((idx + diff) % len(siblings)), node)
ZeroDivisionError: integer division or modulo by zero

• There's some off-by-one error in tree-tab-bubble: tree-tab-bubble down run in the second last group swaps the group with the first group instead of the last group.

• tree-tab-rotate down often doesn't do anything, tree-tab-rotate up works fine.

• set tabs.new_position.unrelated next is not honored anymore. Even tree-tab-promote sends tabs to the end of tab bar.

• tree-tab-navigate-on-same-level takes argument prev/next, other commands take up/down. Better be consistent.

• Saving the session has worked well so far.

• Moving a group to a specific number would be useful. tab-move currently doesn't make a lot of sense.

@arza-zara, thank you so much for the testing!
Some of these errors were so dumb I don't know how they happened. Anyways, I fixed all the issues you pointed out!

The tip on tab-move was incredibly useful! It wasn't easy to implement it right, but now it's a very powerful command to move trees around.

@pinusc It's probably time to open a PR with your changes! 😉 PRs don't need to be perfect, you can still update them by pushing new commits to your branch. That way, people can comment e.g. on individual lines much easier.

@pinusc First off - thank you for your work, this is really useful already.

I have another feature request: could we add an additional command to "cycle" through the visibility of the current tab's hierarchy, while keeping the window-contents unchanged? It's a bit hard to explain, I mean something like this:

unfolded:

<root>
      <p1>
          <p2>
               <child>      <------ selected in tabbar, and shown in window

cycle once:

<root>
      <p1>
          <p2...>              <------- selected in tabbar, but now shown in window

cycle twice:

<root>
      <p1...>                  <-------- selected in tabbar, but not shown in window

cycle thrice: already at root-most node -> back to the beginning

<root>
      <p1>
          <p2>
               <child>      <------ selected in tabbar, and shown in window

Next-/Previous/New-tab commands could act on the tab selected in the tabbar, not the one shown in the window.

With this scheme, the user could get a quick idea of the current hierarchy's structure by cycling through it while keeping screen movement minimal. He could intuitively act on that screen hierarchy by stopping to cycle at the appropriate moment, and issue commands to change the window's content or create new tabs, etc. .

Of course, this would require the decoupling between tabs selected and folded/unfolded in the tabbar, and the current window's content. But I think this could be worth it.

EDIT: one could even implement something like emacs org-mode visibility cycling, where all parent-nodes could be cycled through. That way one could get an idea of all current tab groups, fold or unfold them all at once e.g. to change the group if desired, or get back to the original state...

I haven't thought through the implications of this much, but is there any virtue to some sort of 'history tree' (think undo branches in Vim or undo tree in Emacs) in combination with tree style tabs?
I imagine there's some overlap between the two.
Just had the thought after reading https://medium.com/free-code-camp/lossless-web-navigation-with-trails-9cd48c0abb56 which has some interesting ideas on user visualization of 'trails' which document the set of branches it takes to reach a leaf on this tree.

For that matter, supporting vim undo branch bindings g- and g+ would be an awesome Qutebrowser feature, but perhaps that should be a separate issue for discussion. (https://vim.fandom.com/wiki/Using_undo_branches)