From ArchWiki
Jump to navigation Jump to search

Add wrapper script for dwb-like session handling

I've recently written and started using a "wrapper" script around qutebrowser that uses --basedir and some symlinking from /run to set up separate directories for data/cache/runtime files, while sharing the same config file location, in order to somewhat mimic the behaviour of dwb when it comes to sessions. The script is available here. The-Compiler seems to focus more on making the WebEngine backend more mature (see GitHub issue #572 -- and I fully support that), so it does not seem like that behaviour is going to be added to qutebrowser itself anytime soon, yet I can imagine that especially ex-dwb users might appreciate it. Are there any objections against adding that script to the "Tips and tricks" section of the article? --Ayekat (talk) 17:51, 5 February 2017 (UTC)

Go for it. Jasonwryan (talk) 18:57, 5 February 2017 (UTC)
I've added the script. But now I'm not sure if it would've been better to only add a link to the script instead of inlining it (space?). Also, I'm not sure if the wording is right, or too verbose (this is my first "major" contribution to this wiki). --Ayekat (talk) 19:58, 5 February 2017 (UTC)
Link to the original; that way it will always be up-to-date. Also, all the explanatory material belongs in the README, not here. People wanting to understand what the script does will read it on Github. Jasonwryan (talk) 20:02, 5 February 2017 (UTC)
OK, fixed that. Thanks! --Ayekat (talk) 21:49, 5 February 2017 (UTC)
Close. -- Blackteahamburger (talk) 09:28, 18 June 2020 (UTC)

Remove "QtWebEngine is experimental" notes

The-Compiler has stopped marking the WebEngine backend as experimental (see this commit). Also, starting with v0.11, qutebrowser is packaged to hard-depend on qt5-webengine instead of qt5-webkit (see this commit, there is still a minor packaging bug, though). I would thus suggest removing the notes that mark the WebEngine backend for qutebrowser as experimental. Ayekat (talk) 13:47, 5 July 2017 (UTC)

I agree it's fine to not mark it as experimental anymore, but before making it the default I'd like to take care of migrating cookies over from QtWebKit and adding a config option for the backend so users can revert easily. I'm not that happy with the decision to make it the default in the package, and I sent a mail to the packager this morning. --The Compiler (talk) 14:04, 5 July 2017 (UTC)

The quote should be part of the userscript's --help page if it's so prominent.

It's very unlikely that anyone will execute the userscript from within the qutebrowser environment with the --help flag (and subsequently check the output using :messages), but much more likely that someone will take a look at the userscript and see that comment. Calling the userscript from outside a qutebrowser environment will fail immediately due to missing environment variables. Why is this an issue with the section and not rather, if at all, a bug report in the qutebrowser repository? --Cryzed (talk) 21:38, 16 November 2017 (UTC)

I'd say it is highly unlikely that qutebrowser's developer would accept a change which introduces duplication in the documentation, so I don't see why the wiki should do otherwise. I hope the scripts options are not supposed to be discovered only by reading the source code. If the usage of each userscript is not very clear, the interface should be improved. For example, running the script with --help from the terminal should not result in an error due to missing environment variables, but rather, if the environment is wrong, the help page should be printed implicitly. Then you can simply instruct users to run the script in terminal to know all about it, without any external documentation.
Anyway, since you seem to be the author of the userscript, consider this to be the bug report ;-)
-- Lahwaacz (talk) 06:52, 17 November 2017 (UTC)
> I hope the scripts options are not supposed to be discovered only by reading the source code.
That's exactly the case, just like with all the other userscripts: they all have their usages, dependencies, documentation etc. outlined in their comment headers, not in any help pages -- mine just happens to use a proper argument parser that can display a help page on request. Maybe it's assumed that people who use qutebrowser are mostly tinkeres anyways and thus don't really mind taking a quick look at a script's source to figure out what it does.
> Anyway, since you seem to be the author of the userscript, consider this to be the bug report ;-)
Right, I got that part. I was just wondering why you would create it here in the first place, instead of through the proper channels ;-). Your requested changes can already be found here for now; I'll see about creating a matching pull request. --Cryzed (talk) 11:36, 17 November 2017 (UTC)