111–120 of 242 posts
In fact, one feature I am missing in Tree Style Tabs is the ability to save a list of tabs as a text file to archive it and to open/import it at a later point in time again.
Somehow TabFS feels like it could be used to achieve that.
However, I think a less powerful extension that just subscribes to `chrome.(tab|window).*` events and reports them to a local server and listens for commands (e.g to create tabs) would be enough. Not using the debug api and not exposing more than tabs, windows and URLs.
The reporting bit of the extension could be as simple as a bunch of listeners a la:
chrome.tabs.onSelectionChanged.addListener(
(tabId, props) => fetch('http://localhost:8118/report?'+JSON.stringify([tabId, props])));KDE on Linux used to have something similar in the late 90s - it allowed you to open a website URL as a directory listing, so you could browse the site's asset directories and open image files, etc. Think like a client-side generated version of Apache's index pages, but using your local file manager. It was a plugin to the VFS framework (KIO) the desktop and all the apps use, so it would also work e.g. in Open File d…
I suspect it would be harder to pull off these days without launching chrome headless for example. Opening the page itself wouldn't include images/resources loaded over JS. It would also not work great with image atlases.
You can paste any KIO URI into any application's file open dialog box and it'll retrieve it. So for example, you could open any KDE media player, paste in an audiocd:// URI, and it'll play the specified track from your CD.
And it also meant that any application could open remote files without having to manually download them first. Like, if I wanted to open some random file off the web in a text editor, I can just go into Kate, hit Ctrl-O, and paste its URL into the dialog box, and it'll fetch it into a temp folder and open it without me having to first download it manually. This was especially useful for PDFs, because Okular is generally way better than any browser's PDF reader (and I was doing this before most browsers came with PDF readers).
It would be cool if the DOM was exposed. Then you could write one liner bash scripts to do simple tasks like “download all images” or “delete script tags referencing spammyads.js”, all with nothing more advanced than find, cp, rm and mv in the shell. E.g. cp html/body/*/img/.hero-img/hello.png ~Downloads/ You would need some clever way to express the DOM with ids and classes etc but it could be done with some subdire…
Cool idea, but I'd worry about all the malformed markup.
The DOM represents the tree structure derived from the markup by the browser, so dealing with malformed markup wouldn't be the problem of this extension, it'd be the problem of the browser it's integrating in to.
"mnt/tabs/by-id/*/title.txt" asks your shell to expand a wildcard match, generating a list of files holding the title of each tab. If I were to feed it into a command-line app, I might start running into command length limits. Would it work better as a "relational database" than a hierarchical tree filesystem? I noticced that "by-id" and "by-title" and "last-focused" are several views into an underlying source of dat…
i upvoted because it's an interesting question, but to me i would like good patterns for how to express data & views on the file-system. data goes into databases to die, alas. it remains tragically single consumer, one database one application. not that it has to be, but that's how things usually are. the file system by contrast is exposed system wide, & requires no app configuration or discovery to consume data on it (I guess choosing a file might sort of count?). there are a wide range of command line and gui tools built in to the os for exploring & manipulating the file system.
perhaps we could make a good sql on the file-system plugin, to make sql data more accessible across the system? :)
This is a brilliant piece of work. As someone who has thousands of tabs open, I've always wanted to "close all tabs with a single command", or view all the open tabs and mass select them and close, for years. Otherwise, going through them one by one and deleting takes forever. Now somebody make a vim pluggin so I can delete tabs by visual selecting a bunch of them and typing "d".
>thousands of tabs open yeah about that, are you sure they are open and not hibernated? Chrome had proactive-tab-freeze-and-discard , later renamed to proactive-tab-freeze and finally forced On in 80 with no option of turning it off. 'hibernated' tabs are merely a bookmark without loaded content. I dont think this extension would be able to work with non loaded tabs without forcing them all to load. 300 tabs is able…
Earlier quoted context omitted.
Without even bothering to check, this seems like it can't possibly be true. You are surely not saying that the billions of Chrome users worldwide have no browsing history from September or earlier, right?
"Your History page shows the webpages you've visited on Chrome in the last 90 days."[0] Google's My Activity[1] stores everything though. [0] https://support.google.com/chrome/answer/95589 [1] https://myactivity.google.com/myactivity
KDE on Linux used to have something similar in the late 90s - it allowed you to open a website URL as a directory listing, so you could browse the site's asset directories and open image files, etc. Think like a client-side generated version of Apache's index pages, but using your local file manager. It was a plugin to the VFS framework (KIO) the desktop and all the apps use, so it would also work e.g. in Open File d…
It then (IIRC 15 years ago) became deprecated in favor of DBUS, but I remember it was not as straightforward and simple to use as DCOP was, and also the applications, at least by the time, weren't supporting lots of useful operations with DBUS.
> bt (brotab = Browser Tabs) is a command-line tool that helps you manage browser tabs. It can help you list, close, reorder, open and activate your tabs.
It supports both Chrome and Firefox. I use it to get titles of tabs that make some sound in Firefox.
KDE on Linux used to have something similar in the late 90s - it allowed you to open a website URL as a directory listing, so you could browse the site's asset directories and open image files, etc. Think like a client-side generated version of Apache's index pages, but using your local file manager. It was a plugin to the VFS framework (KIO) the desktop and all the apps use, so it would also work e.g. in Open File d…
I wonder if they were inspired by BeOS. These days many desktop interfaces feel quite dumbed-down. Still very usable though. But perhaps sometimes with unrealized potential.