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)
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
--helpfrom 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)