-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tree style tabs #927
Comments
killer feature |
👍 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? |
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? 😉 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. 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:
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:
When a tab with children is closed, behavior is either (depending on user options):
Opening a link in a new tab:
Creating a tab (depends on how it's opened):
A simplified version for QB could be to:
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. |
That would only cover part of the usecase. What you described is closer
to Firefox's Panorama/Tab Groups, or Vivaldi's Tab Stacks. Trees are a
very different visualization, they provide origin information in
addition to just context, and they are both visually integrated into the
normal tabs and distinctive. Tab Groups are too big of a separation, and
Stacks make them too compact for my taste.
|
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. |
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 :-) |
@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:
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 :
or
or even, as a divider :
...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 (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. |
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 :
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 " 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 |
@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? |
Giuseppe Stelluto writes:
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?
Right now, there's quite a large backlog of PRs that need to be merged, the
best contribution that people can make is providing reviews for existing PRs.
If you want to work on this directly though, the starting point would probably
be updating the patch linked in this issue to work on latest master without
the anytree dependency, adding tests, and making sure it's clean/stable.
|
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! 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 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:
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 |
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:
|
@arza-zara, thank you so much for the testing! The tip on |
@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:
cycle once:
cycle twice:
cycle thrice: already at root-most node -> back to the beginning
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? |
For that matter, supporting vim undo branch bindings |
Like the tree style tabs Firefox addon.
The text was updated successfully, but these errors were encountered: