qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Trilby · 2017-02-25 14:52:29

It'd still be pretty simple. Something along the lines of the following could be an alias/function:

sqlite3 /path/to/db ".mode tabs" "select * from history" > /tmp/history &&
   $EDITOR history &&
   sqlite3 /path/to/db ".mode tabs" "delete from history" ".import /tmp/history"

Of course this isn't nearly as simple as "$EDITOR /path/to/history", but it also allows for more powerful filtering.

SubS0 · 2017-03-01 10:28:39

I switched from webkit to webengine when v.10.0 were announced. I’m happy with it.

I encounter a problem similar to #2317 with compose-key, but on every input field. I can't write ^ or a letter like â.

In fact, I can : it seems that when opening a tab and going on insert field a first time, it is impossible to use the compose-key. Going to another open tab, and coming back to the first one, and the compose-key is available ! I can reproduce this behavior every time, everywhere (even on the sbb.ch input fields present in the issue report opened by The-Compiler).

parchd · 2017-03-01 10:32:46

SubS0 wrote:

I switched from webkit to webengine when v.10.0 were announced. I’m happy with it.
I encounter a problem similar to #2317 with compose-key, but on every input field. I can't write ^ or a letter like â.
In fact, I can : it seems that when opening a tab and going on insert field a first time, it is impossible to use the compose-key. Going to another open tab, and coming back to the first one, and the compose-key is available ! I can reproduce this behavior every time, everywhere (even on the sbb.ch input fields present in the issue report opened by The-Compiler).

Ooh, that is a useful workaround! Thanks for sharing!

ayekat · 2017-03-01 10:33:30

SubS0 wrote:

In fact, I can : it seems that when opening a tab and going on insert field a first time, it is impossible to use the compose-key. Going to another open tab, and coming back to the first one, and the compose-key is available ! I can reproduce this behavior every time, everywhere (even on the sbb.ch input fields present in the issue report opened by The-Compiler).

Nice observation
The same appears to be the case for dead keys (I always opened the external editor whenever I had to type something that required me to use dead keys).

The Compiler · 2017-03-07 06:39:28

Thanks for that! Ways to consistently reproduce a bug are really useful, especially when reporting it upstream

Ambrevar · 2017-03-07 09:32:07

I'm wondering if this is a bug (on qtwebengine at least): whenever I follow-open a tab in the background, I lose focus on the current tab (e.g. <space> does not work anymore).

Step to reproduce:

- Open a long page on arch wiki.
- Check that <space> scrolls down.
- follow-hint in the background.
- <space> does not scroll down anymore.

On a related topic, some pages have different scrollable areas. Is it possible to change the focus using key bindings?

lahwaacz · 2017-03-07 09:37:01

It seems there is a report for this bug, although the description involves closing a tab: https://github.com/qutebrowser/qutebrowser/issues/2403

The Compiler · 2017-03-07 09:43:09

I added a comment about that to that issue.

On a related topic, some pages have different scrollable areas. Is it possible to change the focus using key bindings?

See this comment.

SubS0 · 2017-03-07 14:25:25

While we’re on the subject, <space> stay attached to input field when you press <escape>, so you don’t recover scrolling with <space> and continue to add spaces on input. Have to press <escape> a second time (other keys are ok).

Last edited by SubS0 (2017-03-07 14:26:39)

wkd · 2017-03-07 17:08:21

I'm currently testing the webengine backend and I noticed it doesn't fully respect private browsing.
In particular the files in
~/.local/share/qutebrowser/webengine
and
~/.cache/qutebrowser/webengine
are still being generated and retained over multiple sessions. This includes cached pictures and visited links.
Is this a bug or is private browsing just not fully implemented into this backend yet?

The Compiler · 2017-03-07 17:28:15

It's not implemented yet - that's why you get an error when trying to set it via :set

wkd · 2017-03-07 18:15:45

Oh, cool, thanks for letting me know. Didn't catch that error since I already had private mode set permanently with the old backend. Anyway, other than that webengine so far is really nifty.

Grus · 2017-03-10 04:23:22

Is it possible yet to configure a certain type of link (a matched string, like youtube.com) to launch in another application rather than a qutebrowser tab when trying to open it directly, by clicking on it? Instead of spawning hints to specifically execute a specific command on a link, would it be configurable for certain domains never to launch a tab/instance and instead passing the link to another command when qutebrowser tries to open them?

The Compiler · 2017-03-10 04:46:05

No - that'll probably be available once there's a plugin API.

rdeckard · 2017-04-10 14:46:43

Hey The Compiler, is brotli implemented in qutebrowser (specifically with webengine)?

The Compiler · 2017-04-10 16:16:18

There's nothing qutebrowser needs to do to support it - but yes, it works: http://httpbin.org/brotli

rdeckard · 2017-04-10 16:43:50

Okay, thanks, that's a good resource. I asked because with Chromium (as well as Firefox) the accept-encodings include "br" when using https, but qutebrowser does not.

The Compiler · 2017-04-10 17:02:46

Hm, indeed - I opened QTBUG-60049 now.

The Compiler · 2017-04-12 20:31:18

Brotli support was fixed in Qt now.

Trilby · 2017-04-13 19:19:51

I've been having trouble with the primary selection in qutebrowser. I've only just tracked down a pattern with it. When I selected text in qutebrowser (using the mouse) and try to paste elsewhere, I frequently get extra text pasted.

If found that this is 100% repeatable when the source is a textarea or input boxes. For example, if I select just these bolded words from my post while I'm typing it, I get quite a bit extra content copied into the primary selection, specifically:

xsel wrote:

is 100% repeatable when the source is a textarea or input boxes. For example, if I select just these bolded words from my post while I'm typing it, I get quite a bit extra content copied into the primary selec

What is copied to the primary selection seems to be the selected text plus exactly 100 characters before the start of the selected text (or up to the start of the textarea/input content) and 100 characters after the end of the selected text (or up to the end of the content).

parchd · 2017-04-13 20:43:17

That might be the issue, or one of the issues, with primary selection I've been noticing. I'd always assumed nothing was getting selected, but now I realise it could have been that too much was being selected and I just thought it was from a previous selecting.

Trilby · 2017-04-13 20:58:30

Parchd, that was my initial suspicion too.

The Compiler · 2017-04-13 22:21:59

Looks like another QtWebEngine issue - reported as QTBUG-60174.

parchd · 2017-04-14 05:51:52

The Compiler wrote:

Looks like another QtWebEngine issue

Wow! I would never have expected that. QtWebEngine is usually so perfect!

The Compiler · 2017-04-18 15:16:21

I just started qutebrowser's second crowdfunding campaign, with the goal of implementing the new config system.

This will finally make it possible to have a config file which doesn't get touched by qutebrowser, allow to set some settings per-domain (e.g. JavaScript support, like NoScript), and much more! After that, it'll also be time to release qutebrowser v1.0.

I'd appreciate your support, it'd be awesome if I could work full time on qutebrowser during my summer holidays again!

Arch Linux

#476 2017-02-25 14:52:29

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#477 2017-03-01 10:28:39

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#478 2017-03-01 10:32:46

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#479 2017-03-01 10:33:30

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#480 2017-03-07 06:39:28

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#481 2017-03-07 09:32:07

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#482 2017-03-07 09:37:01

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#483 2017-03-07 09:43:09

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#484 2017-03-07 14:25:25

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#485 2017-03-07 17:08:21

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#486 2017-03-07 17:28:15

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#487 2017-03-07 18:15:45

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#488 2017-03-10 04:23:22

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#489 2017-03-10 04:46:05

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#490 2017-04-10 14:46:43

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#491 2017-04-10 16:16:18

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#492 2017-04-10 16:43:50

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#493 2017-04-10 17:02:46

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#494 2017-04-12 20:31:18

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#495 2017-04-13 19:19:51

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#496 2017-04-13 20:43:17

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#497 2017-04-13 20:58:30

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#498 2017-04-13 22:21:59

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#499 2017-04-14 05:51:52

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#500 2017-04-18 15:16:21

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Board footer