Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coming to Chrome: a new way to use tabs

blog.google

Post reply on HN
Print view View original

341–350 of 392 posts

Re: Coming to Chrome: a new way to use tabs

#341

Post by TheArcane »

Tobu wrote: post #313
TheArcane wrote: post #241

Earlier quoted context omitted.

The worst part is that % cannot search across containers I'm baffled how firefox hasn't figured this out yet

Here's the bug [1]; apparently someone made it so on purpose [2]. In related issues, I'd like switch to tab to be consistent so that ctrl-clicking on an awesomebar result always opens it in a new tab, instead of depending on whether it found a tab or not. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1287866

> apparently someone made it so on purpose [2]

This is terribly unfortunate, given that there are many active bugs associated with this: https://bugzilla.mozilla.org/show_bug.cgi?id=1479858 https://bugzilla.mozilla.org/show_bug.cgi?id=1500991 https://bugzilla.mozilla.org/show_bug.cgi?id=1538069

I've read the thread you linked and I still don't understand their reasoning for this.

Re: Coming to Chrome: a new way to use tabs

#342

Post by grapenut »

abjKT26nO8 wrote: post #208
DonHopkins wrote: post #167

Earlier quoted context omitted.

Why WOULDN'T you want to be able to use tabs on all of your windows? And why WOULDN'T you want to be able to move any tab to any edge (top, bottom, left, right) of any window? And why WOULDN'T you want to be able to group and stack and tile tabbed windows from different applications together?

What I would like, is Emacs/Vim-style buffers. When you don't have one open, it's completely invisible. When you want to switch to it, you perform an incremental search for its title. No need to hunt for things on the screen. A lot faster and a lot more tidy wrt what's currently visible on the screen. No distractions.

If you're willing to go whole-hog, I've had good experiences using EXWM for this.

Re: Coming to Chrome: a new way to use tabs

#343

Post by maciekmm »

akincisor wrote: post #340
maciekmm wrote: post #90

Earlier quoted context omitted.

Shameless plug. I made the ContainerTabsSidebar firefox addon[0], which is inspired by the TST. It groups tabs based on firefox privacy containers, which means every container has an isolated cookie store. I'm a tab hoarder and developed it to work for such "use-case". It's very similar to the groups presented, but displays tabs vertically. [0]: https://addons.mozilla.org/en-US/firefox/addon/container-tab...

Is it possible to have the hierarchical structure of tabs like in tree style tabs (so I can see which tab spawned which tabs)?

It's not. But please make an issue on github[0] and if there's enough demand I will think about implementing this :) Contributions are also welcome, though the codebase currently needs a bit of a refactor.

[0]:https://github.com/maciekmm/container-tabs-sidebar

Re: Coming to Chrome: a new way to use tabs

#344

Post by waddlesplash »

qubex wrote: post #299
waddlesplash wrote: post #264

Earlier quoted context omitted.

Haiku, the BeOS' spiritual successor, did develop the feature further into "Stack & Tile": https://www.haiku-os.org/docs/userguide/en/gui.html#stack-ti...

Beautiful. I’ve got a recent build of Haiku in a VM and I didn’t even know this feature existed! Thank you.

Yes, the Haiku User Guide is worth reading, there are a lot of little gems in there that are not easily discoverable otherwise :)

Re: Coming to Chrome: a new way to use tabs

#346

Post by YennaV »

maciekmm wrote: post #339
YennaV wrote: post #333

Earlier quoted context omitted.

How does your extension interact with Temporary Containers ( https://addons.mozilla.org/en-US/firefox/addon/temporary-con... )? I am a tab hoarder too and I use Temporary Containers to create ephemeral sessions.

It's currently not the best experience as the temporary containers addon creates a container per browser tab which bloats the sidebar. But there's a github issue for it and I've received a couple of requests regarding this today, so I will tackle this ASAP.

Great to hear. Thanks much!

Re: Coming to Chrome: a new way to use tabs

#349

Post by jpeloquin »

baxtr wrote: post #257
maciekmm wrote: post #90

Earlier quoted context omitted.

Shameless plug. I made the ContainerTabsSidebar firefox addon[0], which is inspired by the TST. It groups tabs based on firefox privacy containers, which means every container has an isolated cookie store. I'm a tab hoarder and developed it to work for such "use-case". It's very similar to the groups presented, but displays tabs vertically. [0]: https://addons.mozilla.org/en-US/firefox/addon/container-tab...

This feels like tabs are becoming bookmarks

Tabs and bookmarks still feel pretty different. To update a tab, you activate the tab and then click links as usual. To update a bookmark, you activate the bookmark, click links, delete the old bookmark, create a new bookmark, and drag the new bookmark to the old one's location in the bookmark list (unless I've missed a shortcut here). Tabs feel very dynamic and are useful as a list or queue of work-in-progress, and bookmarks feel very static and are useful as a permanent list of important resources.

Re: Coming to Chrome: a new way to use tabs

#350

Post by floatingatoll »

metroholografix wrote: post #311
floatingatoll wrote: post #87

Earlier quoted context omitted.

This looks very useful, but it combines valuable profile management work with disabling various web features per the author's opinions. Sadly, disabling those features by default makes it significantly easier to fingerprint users using this script (which is precisely the opposite of its intentions). So I forked it and set those features to be disable-if-requested rather than disable-by-default, so that people who jus…

Forking to switch a bunch of command line arguments around seems excessive to me. You can simply write a wrapper script that passes the arguments in the way you want them to be passed. Enabling those options does nothing to improve fingerprinting resistance, it's a completely bogus argument. Disabling them however, in combination with the recommended extensions that are in the README plus custom user agent handling,…

Forking permits me to efficiently git rebase against upstream when there are changes, using rerere to remember easy conflict resolutions. A wrapper would not work as two of the options cannot be removed from the command line (and the author refused a PR that would have permitted such a wrapper).
Post reply on HN