Hi
Just jumping in, but I have a setup on i3wm where through the i3 IPC I
send an ordered history of recently-opened windows to an open port on
localhost so I can then pick them up from other scripts.
One of those scripts just filters for "qutebrowser" and returns all the
open qutebrowser "tabs". I use this from rofi to get me a list of open
browser windows, most recently opened on the top.
One tricky thing is that for this setup I need to include the i3 window
id (con_id) in the script that returns the windows to rofi, otherwise I
can't actually find back the window from the script (I have no way to
identify it).
I'd be curious to hear if anybody else has found other ways to do this.
Chris
On 01/29@22:54, Matt wrote:
I suppose you use a tiling WM ? in which case you could force every
new tab as a new window and use rofi window switcher (works for
i3wm.com, not sure for other WM though).
Then I am not sure qutebrowser is capable of syncing history between
instances (like zsh or neovim do) ? which can be annoying
2016-01-29 10:54 GMT+01:00 Florian Bruhin <[email protected]>:
Hey,
* Stefan Tatschner <[email protected]> [2016-01-29 10:28:51 +0100]:
I often have a lot of tabs open in qutebrowser. So I am looking for a
solution to deal better with a lot of tabs. I have come to the idea that
some dmenu/rofi userscript would be fine.
IMHO ideally this would be integrated into qutebrowser's completion,
see this issue: https://github.com/The-Compiler/qutebrowser/issues/32
Unfortunately I'm working on stuff which is higher priority right now,
probably for some more months (tests, QtWebEngine, per domain
settings, plugins).
I'm still hoping someone will contribute that one ;)
That script should get a list of all currently opened tabs, pipe it into
dmenu/rofi and finally send some "please change to tab number soandso"
command to qutebrowser.
I have not yet found a qutebrowser command to get a list of all opened
tabs. Am I missing something?
There isn't. You'd typically do this via an userscript, and there's
currently no way for an userscript to request more information (or get
"answers" to commands it sends).
qutebrowser could expose this information to userscripts via an
environment variable, e.g. some $QUTE_TABS variable set to something
like:
0 0 url title of first tab in first window
0 1 url title of second tab in first window
[...]
The problem with that approach is that it might be too much data for
an environment variable, so maybe $QUTE_TABS would need to be a
filename of a temporary file, like $QUTE_HTML and $QUTE_TEXT is.
Then again I'm not sure how much it makes sense to shoehorn all
possible usecases into somewhat fragile userscripts. I'd rather see
plugins written in Python (or possibly JS at some later point), but it
might still take a while until that's ready.
Florian
--
http://www.the-compiler.org | [email protected] (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
