From blackmailingferret at gmail.com Sat Jan 4 23:17:51 2020 From: blackmailingferret at gmail.com (Martin) Date: Sat, 4 Jan 2020 23:17:51 +0100 Subject: [qutebrowser] Feature request: Alternative to c.tabs.show_switching_delay Message-ID: <60108340-3629-95fe-5d6f-84182b9679f2@gmail.com> Hi, for the feature "c.tabs.show = 'switching'" one can set "c.tabs.show_switching_delay = 1200" in order to control, how long the tab bar is shown. Since the tabs are switched with shift+j or shift+k, I think a better solution would be to show the tabs as long as the shift key is held down, after pressing shift+j. >From a user perspective, this seems very natural behavior to me, and it is least annoying, since: Sometimes I want to see the tabs for a long time (searching a long list) Sometimes I want the tabs to disappear asap. What do you think? Best regards and thanks for the great browser, Martin From me at the-compiler.org Sat Jan 4 23:32:25 2020 From: me at the-compiler.org (Florian Bruhin) Date: Sat, 4 Jan 2020 23:32:25 +0100 Subject: [qutebrowser] Feature request: Alternative to c.tabs.show_switching_delay In-Reply-To: <60108340-3629-95fe-5d6f-84182b9679f2@gmail.com> References: <60108340-3629-95fe-5d6f-84182b9679f2@gmail.com> Message-ID: <20200104223225.a3cgpo3pa6vba7xd@hooch.localdomain> Hey Martin, On Sat, Jan 04, 2020 at 11:17:51PM +0100, Martin wrote: > for the feature > "c.tabs.show = 'switching'" > one can set > "c.tabs.show_switching_delay = 1200" > in order to control, how long the tab bar is shown. > > Since the tabs are switched with shift+j or shift+k, I think a better > solution would be to show the tabs as long as the shift key is held > down, after pressing shift+j. > > From a user perspective, this seems very natural behavior to me, and it > is least annoying, since: > Sometimes I want to see the tabs for a long time (searching a long list) > Sometimes I want the tabs to disappear asap. > > What do you think? qutebrowser's input model is centered on commands being bound to keys. Without hardcoding things (which isn't really a possibility - there are no hardcoded keybindings), that means there's no way to say "do this when shift is pressed/released". Also, other people might use non-default keybindings (like gt/gT) for switching tabs. It's a bit similar to this: https://github.com/qutebrowser/qutebrowser/issues/4768 If you have an idea how any of those ideas would fit in well with qutebrowser's configuration, I'm all ears! The only thing I could think of so far is qutebrowser doing some magic (if tab switching commands happen to be bound to a keybinding with modifier, do what you proposed with that modifier key), but that seems quite cumbersome (both to implement and to explain). Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ben.hengst at gmail.com Sun Jan 5 00:27:49 2020 From: ben.hengst at gmail.com (benh) Date: Sat, 4 Jan 2020 15:27:49 -0800 Subject: [qutebrowser] Feature request: Alternative to c.tabs.show_switching_delay In-Reply-To: <20200104223225.a3cgpo3pa6vba7xd@hooch.localdomain> References: <60108340-3629-95fe-5d6f-84182b9679f2@gmail.com> <20200104223225.a3cgpo3pa6vba7xd@hooch.localdomain> Message-ID: It's been a while since I looked but can an outside process effect the state of the bar? If so then could this key watching behavior can be offloaded to an outside script? On Sat, Jan 4, 2020, 14:32 Florian Bruhin wrote: > Hey Martin, > > On Sat, Jan 04, 2020 at 11:17:51PM +0100, Martin wrote: > > for the feature > > "c.tabs.show = 'switching'" > > one can set > > "c.tabs.show_switching_delay = 1200" > > in order to control, how long the tab bar is shown. > > > > Since the tabs are switched with shift+j or shift+k, I think a better > > solution would be to show the tabs as long as the shift key is held > > down, after pressing shift+j. > > > > From a user perspective, this seems very natural behavior to me, and it > > is least annoying, since: > > Sometimes I want to see the tabs for a long time (searching a long list) > > Sometimes I want the tabs to disappear asap. > > > > What do you think? > > qutebrowser's input model is centered on commands being bound to keys. > Without > hardcoding things (which isn't really a possibility - there are no > hardcoded > keybindings), that means there's no way to say "do this when shift is > pressed/released". Also, other people might use non-default keybindings > (like > gt/gT) for switching tabs. > > It's a bit similar to this: > https://github.com/qutebrowser/qutebrowser/issues/4768 > > If you have an idea how any of those ideas would fit in well with > qutebrowser's > configuration, I'm all ears! The only thing I could think of so far is > qutebrowser doing some magic (if tab switching commands happen to be bound > to a > keybinding with modifier, do what you proposed with that modifier key), but > that seems quite cumbersome (both to implement and to explain). > > Florian > > -- > me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org > https://bruhin.software/ | > https://github.com/sponsors/The-Compiler/ > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Sun Jan 5 13:06:29 2020 From: me at the-compiler.org (Florian Bruhin) Date: Sun, 5 Jan 2020 13:06:29 +0100 Subject: [qutebrowser] Feature request: Alternative to c.tabs.show_switching_delay In-Reply-To: References: <60108340-3629-95fe-5d6f-84182b9679f2@gmail.com> <20200104223225.a3cgpo3pa6vba7xd@hooch.localdomain> Message-ID: <20200105120629.kowpcardebswdgef@hooch.localdomain> On Sat, Jan 04, 2020 at 03:27:49PM -0800, benh wrote: > It's been a while since I looked but can an outside process effect the > state of the bar? If so then could this key watching behavior can be > offloaded to an outside script? You could probably run something like this from a script qutebrowser ':set tabs.show always' (or never) I guess it'd work, but it'd be quite a hack :D Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From me at the-compiler.org Tue Jan 7 19:17:03 2020 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 7 Jan 2020 19:17:03 +0100 Subject: [qutebrowser] Log in to Google Account using qutebrowser In-Reply-To: <20191204122826.2vqgqc6ck63zf2sj@hooch.localdomain> References: <20191203154003.j2wbfann52xhb577@hooch.localdomain> <24467c4684924380bfe1acb9d51db4bb@practicemax.com> <20191204122826.2vqgqc6ck63zf2sj@hooch.localdomain> Message-ID: <20200107181703.ui25hgbowqf6amwt@hooch.localdomain> Hey, On Wed, Dec 04, 2019 at 01:28:26PM +0100, Florian Bruhin wrote: > On Wed, Dec 04, 2019 at 12:39:44PM +0100, Denis Khizhniak wrote: > > So, I have no idea how Google checks the actual browser and whether it's > > possible to fool him. > > Neither do I. Chances are that as soon as someone finds a solution, Google will > just adjust whatever checking they do to break it again. FWIW, there is a workaround for this which seems to work so far. The upcoming qutebrowser v1.9.0 release will contain it, but in the meantime you can do the same via :set as well. See this writeup for details: https://github.com/qutebrowser/qutebrowser/issues/5182 > There are some people who claim to have a solution, but don't want to talk > about it publicly - precisely because it'll just end up in Google blocking that > as well. I was wrong there. I contacted them to see what'd happen. One of them told me to "try out" his solution and sent me to a phishing page, trying to get me to log in with my Google Account there. The other asked me for $2000 for his solution. Unsurprisingly, I declined both offers. So much about Google making things more secure. Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From 4denis.kh at gmail.com Tue Jan 7 19:41:43 2020 From: 4denis.kh at gmail.com (Denis Khizhniak) Date: Tue, 7 Jan 2020 19:41:43 +0100 Subject: [qutebrowser] Log in to Google Account using qutebrowser In-Reply-To: <20200107181703.ui25hgbowqf6amwt@hooch.localdomain> References: <20191203154003.j2wbfann52xhb577@hooch.localdomain> <24467c4684924380bfe1acb9d51db4bb@practicemax.com> <20191204122826.2vqgqc6ck63zf2sj@hooch.localdomain> <20200107181703.ui25hgbowqf6amwt@hooch.localdomain> Message-ID: Yeah, thank you Florian, Till now I was using the workaround that you've shared before and it's working perfect?. Kind regards, Denis Khizhniak On Tue, 7 Jan 2020, 19:17 Florian Bruhin wrote: > Hey, > > On Wed, Dec 04, 2019 at 01:28:26PM +0100, Florian Bruhin wrote: > > On Wed, Dec 04, 2019 at 12:39:44PM +0100, Denis Khizhniak wrote: > > > So, I have no idea how Google checks the actual browser and whether > it's > > > possible to fool him. > > > > Neither do I. Chances are that as soon as someone finds a solution, > Google will > > just adjust whatever checking they do to break it again. > > FWIW, there is a workaround for this which seems to work so far. The > upcoming > qutebrowser v1.9.0 release will contain it, but in the meantime you can do > the > same via :set as well. See this writeup for details: > https://github.com/qutebrowser/qutebrowser/issues/5182 > > > There are some people who claim to have a solution, but don't want to > talk > > about it publicly - precisely because it'll just end up in Google > blocking that > > as well. > > I was wrong there. I contacted them to see what'd happen. > > One of them told me to "try out" his solution and sent me to a phishing > page, > trying to get me to log in with my Google Account there. > > The other asked me for $2000 for his solution. > > Unsurprisingly, I declined both offers. So much about Google making things > more > secure. > > Florian > > -- > me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org > https://bruhin.software/ | > https://github.com/sponsors/The-Compiler/ > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Jan 8 17:24:56 2020 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 8 Jan 2020 17:24:56 +0100 Subject: [qutebrowser] qutebrowser v1.9.0 released! Message-ID: <20200108162456.oajqf37xdthxmzga@hooch.localdomain> Hey, I just released qutebrowser v1.9.0! The main reason for the release is getting the user agent workarounds for pages like Google Accounts and WhatsApp Web out: https://github.com/qutebrowser/qutebrowser/issues/5182 There are also various other changes (thanks to all the contributors involved!), see the changelog below for details. Note the Windows/macOS binaries still ship Qt 5.12 LTS due to bugs in Qt 5.13 and qutebrowser still needing to adjust some stuff for Qt 5.14. Hopefully, there will be a (rather small) v1.10.0 soon-ish, which updates those binaries to Qt 5.14 - stay tuned! Florian Added ~~~~~ - Initial support for Qt 5.14. - New `content.site_specific_quirks` setting which enables workarounds for websites with broken user agent parsing (enabled by default, see the "Fixed" section for fixed websites). - New `qt.force_platformtheme` setting to force Qt to use a given platform theme. - New `tabs.tooltips` setting which can be used to disable hover tooltips for tabs. - New settings to configure the appearance of context menus: - `fonts.contextmenu` - `colors.contextmenu.menu.bg` - `colors.contextmenu.menu.fg` - `colors.contextmenu.selected.bg` - `colors.contextmenu.selected.fg` Changed ~~~~~~~ - The macOS binaries now require macOS 10.13 High Sierra or newer. Support for macOS 10.12 Sierra has been dropped. - The `content.headers.user_agent` setting now is a format string with the default value resembling the behavior of it being set to null before. This slightly changes the sent user agent for QtWebKit: Instead of mentioning qutebrowser and its version it now mentions the Qt version. - The `qute-pass` userscript now has a new `--extra-url-suffixes` (`-s`) argument which passes extra URL suffixes to the tldextract library. - A stack is now used for `:tab-focus last` rather than just saving one tab. Additionally, `:tab-focus` now understands `stack-prev` and `stack-next` arguments to traverse that stack. - `:hint` now has a new `right-click` target which allows right-clicking elements via hints. - The Terminus font has been removed from the default monospace fonts since it caused trouble with HighDPI setups. To get it back, add either `"xos4 Terminus"` or `Terminus` (depending on fontconfig version) to the beginning of the `fonts.monospace` setting. - As a workaround for a Qt bug causing a segfault, desktop sharing is now automatically rejected on Qt versions before 5.13.2. Note that screen sharing still won't work on Linux before Qt 5.14. - Comment lines in quickmarks/bookmarks files are now ignored. However, note that qutebrowser will overwrite those files if bookmark/quickmark commands are used. - Reopening PDF.js pages from e.g. a session file will now re-download and display those PDFs. - Improved behavior when using `:open-download` in a sandboxed environment (KDE Flatpak). - qutebrowser now enables the new PyQt exit scheme, which should result in things being cleaned up more properly (e.g. cookies being saved even without a timeout) on PyQt 5.13.1 and newer. - The `:spawn` command has a new `-m` / `--output-messages` argument which shows qutebrowser messages based on a command's standard output/error. - Improved insert mode detection for some CodeMirror usages (e.g. in JupyterLab and Jupyter Notebook). - If JavaScript is disabled globally, `file://*` now doesn't automatically have it enabled anymore. Run `:set -u file://* content.javascript.enabled true` to restore the previous behavior. - Settings with URL patterns can now be used to affect the behavior of the QtWebEngine inspector. Note that the underlying URL is `chrome-devtools://*` from Qt 5.11 to Qt 5.13, but `devtools://*` with Qt 5.14. - Improvements when `tabs.tabs_are_windows` is set: * Using `:tab-take` and `:tab-give` now shows an error, as the effect of doing so would be equal to `:tab-clone`. * The `:buffer` completion doesn't show any window sections anymore, only a flat list of tabs. - Improved parsing in some corner cases for the `QtFont` type (used for `fonts.tabs` and `fonts.debug_console`). - Performance improvements for the following areas: * Adding settings with URL patterns * Matching of settings using URL patterns Fixed ~~~~~ - Downloads (e.g. via `:download`) now see the same user agent header as webpages, which fixes cases where overly restrictive servers/WAFs closed the connection before. - `dictcli.py` now works correctly on Windows again. - The logic for `:restart` has been revisited, which should fix issues with relative basedirs. - Remaining issues related to Python 3.8 are now fixed (mostly warnings, especially on QtWebKit). - Workaround for a Qt bug where a page never finishes loading with a non-overridable TLS error (e.g. due to HSTS). - The `qute://configdiff` page now doesn't show built-in settings (e.g. javascript being enabled for `qute://` and `chrome://` pages) anymore. - The `qute-lastpass` userscript now stops prompting for passwords when cancelling the password input. - The tab hover text now shows ampersands (&) correctly. - With QtWebEngine and Qt >= 5.11, the inspector now shows its icons correctly even if loading of images is disabled via the `content.images` setting. - Entering a very long string (over 50k characters) in the completion used to crash, now it shows an error message instead. - Various improvements for URL/searchengine detection: - Strings with a dot but with characters not allowed in a URL (e.g. an underscore) are now not treated as URL anymore. - Strings like "5/8" are now not treated as IP anymore. - URLs with an explicit scheme and a space (%20) are correctly treated as URLs. - Mail addresses are now treated as search terms. - With `url.open_base_url` set, searching for a search engine name now works. - `url.open_base_url = True` together with `url.auto_search = 'never'` is now handled correctly. - Fixed crash when a search engine URL turns out to be invalid. - New "site specific quirks", which work around some broken websites: - WhatsApp Web - Google Accounts - Slack (with older QtWebEngine versions) - Dell.com support pages (with Qt 5.7) - Google Docs (fixes broken IME/compose key) -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From enricomaria.dean6elis at gmail.com Sun Jan 12 09:08:51 2020 From: enricomaria.dean6elis at gmail.com (Enrico Maria De Angelis) Date: Sun, 12 Jan 2020 08:08:51 +0000 Subject: [qutebrowser] History Message-ID: Hi all, I was wondering a couple of things: - Why the history folder is not listed in the *Path* section of qute://version/? I don't remember where I am supposed to look for that path. When I forget where it is, I just run a find to find it. - What would be wrong in having the history in a plain text format? I mean, having it that form would allow one to manually edit it, which could be useful in some circumstances. Cheers, Enrico Maria -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Sun Jan 12 10:30:13 2020 From: me at the-compiler.org (Florian Bruhin) Date: Sun, 12 Jan 2020 10:30:13 +0100 Subject: [qutebrowser] History In-Reply-To: References: Message-ID: <20200112093013.gkjod3j5o3mmeimv@hooch.localdomain> Hey, On Sun, Jan 12, 2020 at 08:08:51AM +0000, Enrico Maria De Angelis wrote: > - Why the history folder is not listed in the *Path* section of > qute://version/? I don't remember where I am supposed to look for that > path. When I forget where it is, I just run a find to find it. Because there is no dedicated "history folder". There is a config, data and cache folder (which are all listed in :version) and the history is in the data folder. > - What would be wrong in having the history in a plain text format? I > mean, having it that form would allow one to manually edit it, which could > be useful in some circumstances. Short answer: Mostly performance, because SQL allows to bridge the data to Qt's GUI widgets easily. Also, it's not like it's a completely foreign format, you can edit it by launching sqlite on it. Longer answer: See the discussions here: https://github.com/qutebrowser/qutebrowser/issues/1765 https://github.com/qutebrowser/qutebrowser/pull/2295 Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: