From nishantjr at gmail.com Sun Apr 2 21:52:40 2017 From: nishantjr at gmail.com (Nishant Rodrigues) Date: Sun, 2 Apr 2017 14:52:40 -0500 Subject: [qutebrowser] Is there a way to prevent qutebrowser from re-writing my configuration file? Message-ID: Heya, I'd like to manage the changes I make to qutebowser's config manually, with comments that help understand why I added a setting (rather than what it does) so that a few months down the line I understand what workflows I had in mind for changing that setting. While I could just copy the configuration I've stored in my dot-files repo manually each time I start the browser I'd rather not have behavior specific to qutebrowser. Is there a way to prevent automatic writing to the main configuration file? If not, would you'll accept patches that allow this behaviour? What modifications are made to the configuration when it's written to? Thanks, Nishant -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Sun Apr 2 22:27:55 2017 From: me at the-compiler.org (Florian Bruhin) Date: Sun, 2 Apr 2017 22:27:55 +0200 Subject: [qutebrowser] Is there a way to prevent qutebrowser from re-writing my configuration file? In-Reply-To: References: Message-ID: <20170402202755.heszrtwhh7pcsmbp@hooch> Hey Nishant, On Sun, Apr 02, 2017 at 02:52:40PM -0500, Nishant Rodrigues wrote: > Is there a way to prevent automatic writing to the main configuration file? :set general auto-save-config can help a bit, but IIRC it'll still get overwritten if there are settings which aren't in the qutebrowser config file yet (e.g. after an upgrade). > If not, would you'll accept patches that allow this behaviour? The bad news: no ;-) The good news: The current config code is probably one of the oldest parts of qutebrowser still existing nowadays (from January 2014 or so), and is soon getting a complete makeover. See more details in these issues: https://github.com/qutebrowser/qutebrowser/issues/499 https://github.com/qutebrowser/qutebrowser/milestone/7 This has been cooking for a while, but it's going to be a bigger change (and also mean releasing qutebrowser v1.0, with an incompatible config). However, I'm currently planning qutebrowser's second crowdfunding (watch this mailinglist for the annoucement around easter!) so I can work full-time for a month on this and other things related to v1.0. Notably, qutebrowser's automatic config file (controlled via :set or the qute:settings page) and the (optional) hand-edited config file will be two completely separate files. > What modifications are made to the configuration when it's written to? If a setting qutebrowser knows about is missing in the file, or something gets changed via :set, or something needs to be updated due to config format changes in qutebrowser, it's simply completely rewritten. (As said: currently. No, I'm not happy with it.) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://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 ryan at rcorre.net Sun Apr 2 22:35:42 2017 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Sun, 2 Apr 2017 16:35:42 -0400 Subject: [qutebrowser] Is there a way to prevent qutebrowser from re-writing my configuration file? In-Reply-To: References: Message-ID: <20170402203542.GB8883@zen-arch> Hi Nishant, You can set general->auto-save-config to false to prevent qutebrowser from saving to the config file on exit. There are also plans to completely revamp the config format: https://github.com/qutebrowser/qutebrowser/issues/499 Work on this will hopefully begin soon! -Ryan On Sun 04/02/17 02:52PM, Nishant Rodrigues wrote: > Heya, > > I'd like to manage the changes I make to qutebowser's config manually, with > comments that help understand > why I added a setting (rather than what it does) so that a few months down > the line I understand what workflows > I had in mind for changing that setting. > > While I could just copy the configuration I've stored in my dot-files repo > manually each time I start the browser I'd rather not have behavior > specific to qutebrowser. > Is there a way to prevent automatic writing to the main configuration file? > If not, would you'll accept patches that allow this behaviour? > > What modifications are made to the configuration when it's written to? > > Thanks, > Nishant From nishantjr at gmail.com Mon Apr 3 21:17:35 2017 From: nishantjr at gmail.com (Nishant Rodrigues) Date: Mon, 3 Apr 2017 14:17:35 -0500 Subject: [qutebrowser] Is there a way to prevent qutebrowser from re-writing my configuration file? In-Reply-To: <20170402202755.heszrtwhh7pcsmbp@hooch> References: <20170402202755.heszrtwhh7pcsmbp@hooch> Message-ID: Hey Florain, Ryan, > The good news: The current config code is probably one of the oldest parts of qutebrowser still existing nowadays (from January 2014 or so), and is soon getting a complete makeover. See more details in these issues: OK. That's great news :) Thanks for the great browser! Nishant On 2 April 2017 at 15:27, Florian Bruhin wrote: > Hey Nishant, > > On Sun, Apr 02, 2017 at 02:52:40PM -0500, Nishant Rodrigues wrote: > > Is there a way to prevent automatic writing to the main configuration > file? > > :set general auto-save-config can help a bit, but IIRC it'll still get > overwritten if there are settings which aren't in the qutebrowser config > file yet (e.g. after an upgrade). > > > If not, would you'll accept patches that allow this behaviour? > > The bad news: no ;-) > > The good news: The current config code is probably one of the oldest > parts of qutebrowser still existing nowadays (from January 2014 or so), > and is soon getting a complete makeover. See more details in these > issues: > > https://github.com/qutebrowser/qutebrowser/issues/499 > https://github.com/qutebrowser/qutebrowser/milestone/7 > > This has been cooking for a while, but it's going to be a bigger change > (and also mean releasing qutebrowser v1.0, with an incompatible config). > > However, I'm currently planning qutebrowser's second crowdfunding (watch > this mailinglist for the annoucement around easter!) so I can work > full-time for a month on this and other things related to v1.0. > > Notably, qutebrowser's automatic config file (controlled via :set or the > qute:settings page) and the (optional) hand-edited config file will be > two completely separate files. > > > What modifications are made to the configuration when it's written to? > > If a setting qutebrowser knows about is missing in the file, or > something gets changed via :set, or something needs to be updated due to > config format changes in qutebrowser, it's simply completely rewritten. > (As said: currently. No, I'm not happy with it.) > > Florian > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.larsen at reagan.com Mon Apr 3 21:56:40 2017 From: keith.larsen at reagan.com (Keith Larsen) Date: Mon, 3 Apr 2017 14:56:40 -0500 Subject: [qutebrowser] Discriminant javascript and cookies in qutebrowser Message-ID: <20170403145640.0a51210c@office3.att.net> Hello list, My browser of choice has recently been deprecated (RIP xombrero). Anyway, this put me on a search that ended with qutebrowser! Initial test driving was great and I'm very impressed with all the different platforms you do builds for. However, one of the killer features of xombrero was that javascript and cookies (respectively) could be disabled and then whitelisted or toggled for the session on a per domain/FQDN basis. I'm fairly sure that this sort of thing is not currently configurable with qutebrowser. The purpose of the email is to ask if this sort of functionality is seen as feasible or even useful to the qutebrowser project. Perhaps a script to set the option and open a bookmark... just looking for you thoughts on the matter. All the best, Keith From me at the-compiler.org Mon Apr 3 22:10:18 2017 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 3 Apr 2017 22:10:18 +0200 Subject: [qutebrowser] Discriminant javascript and cookies in qutebrowser In-Reply-To: <20170403145640.0a51210c@office3.att.net> References: <20170403145640.0a51210c@office3.att.net> Message-ID: <20170403201018.ffupk33zridsrmgc@hooch> Hey Keith, On Mon, Apr 03, 2017 at 02:56:40PM -0500, Keith Larsen via qutebrowser wrote: > My browser of choice has recently been deprecated (RIP xombrero). > Anyway, this put me on a search that ended with qutebrowser! Initial > test driving was great and I'm very impressed with all the different > platforms you do builds for. Yay! :) > However, one of the killer features of xombrero was that javascript and > cookies (respectively) could be disabled and then whitelisted or > toggled for the session on a per domain/FQDN basis. > > I'm fairly sure that this sort of thing is not currently configurable > with qutebrowser. The purpose of the email is to ask if this sort of > functionality is seen as feasible or even useful to the qutebrowser > project. It's definitely something which was planned for a long time: https://github.com/qutebrowser/qutebrowser/issues/27 I'm planning to finally make it happen - together with some bigger changes on how configuration works (see [1]) - in my summer holidays, and will launch qutebrowser's second crowdfunding for that soon (so I can work full-time on the whole config stuff and more for a month). [1] https://github.com/qutebrowser/qutebrowser/issues/499 Once it's up, I'll of course announce it on this list (you're not subscribed yet, by the way) as well as the qutebrowser-announce list. > Perhaps a script to set the option and open a bookmark... just looking > for you thoughts on the matter. You can already do that (with a simple keybinding using ;; as command separator), but it'll disable/enable javascript for all open pages. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://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 Apr 18 15:27:42 2017 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 18 Apr 2017 15:27:42 +0200 Subject: [qutebrowser] Crowdfunding campaign for new config system and per-domain settings Message-ID: <20170418132741.thmlmkt4zm6chiyp@hooch.localdomain> Hi, Like last year, I'd love to spend my summer holidays working full-time on qutebrowser again! This is why I started another crowdfunding - with the goal of finally implementing the new config system: https://www.kickstarter.com/projects/the-compiler/qutebrowser-v10-with-per-domain-settings?ref=6tooiw In a nutshell, that means: - There's a separate (optional) config file, which will never be touched by qutebrowser, and is much better suited for people who prefer editing their config by hand and/or managing it in a VCS like git. - Many new possibilities for the config, like setting the backend (QtWebKit/QtWebEngine), or other things which need to be available early (like disabling canvas reading). - The ability to set many settings for individual domains - such as enabling JavaScript individually (like NoScript), or setting user-stylesheets for some pages (like Stylish). - Much more powerful configuration (in Python). - Many other configuration bugs and quirks which will be fixed along the way. Like last year, you can get qutebrowser stickers and t-shirts by contributing to the crowdfunding. Please spread the word! :) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://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 mail at maximilian-kolb.de Wed Apr 19 10:20:08 2017 From: mail at maximilian-kolb.de (Maximilian Kolb) Date: Wed, 19 Apr 2017 10:20:08 +0200 Subject: [qutebrowser] qutebrowser debian package? Message-ID: <9c4c14ca-57bb-b2d0-ea6e-5d81e754f645@maximilian-kolb.de> hey all! i've seen the kickstarter campaign [https://www.kickstarter.com/projects/the-compiler/qutebrowser-v10-with-per-domain-settings] and i was wondering if there are any plans to provide a debian package for qutebrowser? this would be very much appreciated from a security and comfort point of view. happy to hear any updates. thank you! From me at the-compiler.org Wed Apr 19 10:25:10 2017 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 19 Apr 2017 10:25:10 +0200 Subject: [qutebrowser] qutebrowser debian package? In-Reply-To: <9c4c14ca-57bb-b2d0-ea6e-5d81e754f645@maximilian-kolb.de> References: <9c4c14ca-57bb-b2d0-ea6e-5d81e754f645@maximilian-kolb.de> Message-ID: <20170419082509.mflghslhtoltq6zy@hooch.localdomain> Hi Maximilian, On Wed, Apr 19, 2017 at 10:20:08AM +0200, Maximilian Kolb wrote: > hey all! > i've seen the kickstarter campaign > [https://www.kickstarter.com/projects/the-compiler/qutebrowser-v10-with-per-domain-settings] > and i was wondering if there are any plans to provide a debian package > for qutebrowser? this would be very much appreciated from a security and > comfort point of view. There is already a Debian package available on the releases page for every release since a while: https://github.com/qutebrowser/qutebrowser/releases It's not in the repositories yet - but work on that is ongoing. A Debian developer I know has reviewed the newest version of the package this week, and Fritz (who is also on this list) is working on fixing the last few issues. I suggest you subscribe to the related ITP bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832937 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832159 Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 john at lane.uk.net Wed Apr 19 17:08:41 2017 From: john at lane.uk.net (John Lane) Date: Wed, 19 Apr 2017 16:08:41 +0100 Subject: [qutebrowser] IDN spoofing Message-ID: <4dc3b2eb-fa7d-cd52-b371-a368f2bae976@lane.uk.net> Interesting article[1] on the register today about internationalised domain name (IDN) spoofing using Punycode[2]. I think it's quite alarming that many browsers show you what looks like apple.com which in reality is something entirely different. That's something new I've learnt today! This can be configured against in Firefox about:config by setting "network.IDN_show_punycode=true" Is it possible to do this in qutebrowser - I couldn't find a setting for it on "qute:settings" ? What's also interesting is that clicking the "apple.com" link on that register article does not work in qutebrowser with the qt5-webkit-ng backend. It does work with the qt5-webengine backend. [1] https://www.theregister.co.uk/2017/04/18/homograph_attack_again [2] https://en.wikipedia.org/wiki/Punycode From martin at arp242.net Wed Apr 19 17:26:30 2017 From: martin at arp242.net (Martin Tournoij) Date: Wed, 19 Apr 2017 16:26:30 +0100 Subject: [qutebrowser] IDN spoofing In-Reply-To: <4dc3b2eb-fa7d-cd52-b371-a368f2bae976@lane.uk.net> References: <4dc3b2eb-fa7d-cd52-b371-a368f2bae976@lane.uk.net> Message-ID: <1492615590.2239757.949431368.5900E616@webmail.messagingengine.com> On Wed, Apr 19, 2017, at 16:08, John Lane wrote: > Interesting article[1] on the register today about internationalised > domain name (IDN) spoofing using Punycode[2]. > > I think it's quite alarming that many browsers show you what looks like > apple.com which in reality is something entirely different. That's > something new I've learnt today! > > This can be configured against in Firefox about:config by setting > "network.IDN_show_punycode=true" I thought all of this was fixed years ago by normalizing various homographs to their Latin variant. Guess not :-/ There are some other fixes we could do as well. If we see that punicode is being used, we can try to do a lookup to the normalized domain name, and if it exists, use that (possibly with a warning). That way the "Cyrillic Apple" becomes regular ol' apple.com. I don't know how fool-proof unicode normalisation is, though. Unicode is pretty large, so there may be oversights? Another, safer, way would be to improve on the Firefox setting by including a whitelist of codepoints for common "safe" scripts, such as Arabic, Hangul, Chinese, Kanji, and perhaps a few others. If all characters fall in that range: show the codepoints, else show the punycode. That particular domain from the article uses Cyrillic, so we can't add that to the whitelist. From me at the-compiler.org Thu Apr 20 06:24:35 2017 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Apr 2017 06:24:35 +0200 Subject: [qutebrowser] IDN spoofing In-Reply-To: <1492615590.2239757.949431368.5900E616@webmail.messagingengine.com> <4dc3b2eb-fa7d-cd52-b371-a368f2bae976@lane.uk.net> Message-ID: <20170420042434.fldiy7zkm4lnjxde@hooch.localdomain> Hey, On Wed, Apr 19, 2017 at 04:08:41PM +0100, John Lane wrote: > Is it possible to do this in qutebrowser - I couldn't find a setting for > it on "qute:settings" ? Currently it's not. Such a setting would be a first line of defense, but I also want to think some more about fix this properly while still showing the encoded form for "normal" IDN domains (say, a German domain with umlauts in my case). I opened an issue here with some first thoughts: https://github.com/qutebrowser/qutebrowser/issues/2547 > What's also interesting is that clicking the "apple.com" link on that > register article does not work in qutebrowser with the qt5-webkit-ng > backend. It does work with the qt5-webengine backend. Looks like Qt's QUrl doesn't like something about that. While I can open it with QtWebEngine, I can't e.g. copy the URL. I smell some Qt bugs to report... :D On Wed, Apr 19, 2017 at 04:26:30PM +0100, Martin Tournoij wrote: > On Wed, Apr 19, 2017, at 16:08, John Lane wrote: > > Interesting article[1] on the register today about internationalised > > domain name (IDN) spoofing using Punycode[2].k > > > > I think it's quite alarming that many browsers show you what looks like > > apple.com which in reality is something entirely different. That's > > something new I've learnt today! > > > > This can be configured against in Firefox about:config by setting > > "network.IDN_show_punycode=true" > > I thought all of this was fixed years ago by normalizing various homographs to > their Latin variant. Guess not :-/ > > There are some other fixes we could do as well. If we see that punicode is > being used, we can try to do a lookup to the normalized domain name, and if it > exists, use that (possibly with a warning). That way the "Cyrillic Apple" > becomes regular ol' apple.com. > > I don't know how fool-proof unicode normalisation is, though. Unicode is > pretty large, so there may be oversights? I don't think this is a good solution. Apart from it being quite hacky to implement, if I tell the browser to go to the not-quite-apple site, I want it to go *there*, not to apple.com. I'm also not sure if normalization actually does this kind of thing. Cyrillic letters probably have some kind of sensible mapping to latin ones, but what if you happen to find, say, some Chinese or Japanese glyph which just happens to look like a "o" but has nothing to do with it? > Another, safer, way would be to improve on the Firefox setting by including a > whitelist of codepoints for common "safe" scripts, such as Arabic, Hangul, > Chinese, Kanji, and perhaps a few others. If all characters fall in that > range: show the codepoints, else show the punycode. > That particular domain from the article uses Cyrillic, so we can't add that to > the whitelist. Chromium apparently went for a blacklist[1], but I wonder what other creative lookalike glyphs you could find if you searched hard enough... [1] https://chromium.googlesource.com/chromium/src/+/08cb718ba7c3961c1006176c9faba0a5841ec792%5E%21/ Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 john at lane.uk.net Thu Apr 20 11:27:52 2017 From: john at lane.uk.net (John Lane) Date: Thu, 20 Apr 2017 10:27:52 +0100 Subject: [qutebrowser] IDN spoofing In-Reply-To: <20170420042434.fldiy7zkm4lnjxde@hooch.localdomain> References: <20170420042434.fldiy7zkm4lnjxde@hooch.localdomain> Message-ID: <2e3fc727-1ba8-7ce0-6ca6-a251755046ee@lane.uk.net> On 20/04/17 05:24, Florian Bruhin wrote: > > I opened an issue here with some first thoughts: > https://github.com/qutebrowser/qutebrowser/issues/2547 > At a very simplistic level, what would work for me would be an option that I can enable that causes IDN to be highlighted somehow (perhaps inverse video in the status bar, perhaps alternating the two representations?). Personally, I can read the Roman alphabet, accented or not, whether it be English, German or whatever (I may not understand the language I am reading though, but I can interpret the characters I see). I can't read chinese, cryllic, arabic or any other non-latin script. So, for me, an option to highlight non-latin IDN URLs would be a start because I would have no interest in following such links. I realise that won't be a solution for many people but I guess it would cover the majority of the people who would be the target of such a spoofing scheme (i.e. those who primarily use the latin alphabet / ascii character set). I don't know how this stuff works so I'll butt out now, glad to see it's being tracked as an issue on Github. John From me at the-compiler.org Thu Apr 20 21:51:04 2017 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Apr 2017 21:51:04 +0200 Subject: [qutebrowser] IDN spoofing In-Reply-To: <2e3fc727-1ba8-7ce0-6ca6-a251755046ee@lane.uk.net> References: <20170420042434.fldiy7zkm4lnjxde@hooch.localdomain> <2e3fc727-1ba8-7ce0-6ca6-a251755046ee@lane.uk.net> Message-ID: <20170420195104.2o4vk4tf5s4td2ka@hooch.localdomain> Hi, On Thu, Apr 20, 2017 at 10:27:52AM +0100, John Lane wrote: > On 20/04/17 05:24, Florian Bruhin wrote: > > > > I opened an issue here with some first thoughts: > > https://github.com/qutebrowser/qutebrowser/issues/2547 > > > > At a very simplistic level, what would work for me would be an option > that I can enable that causes IDN to be highlighted somehow (perhaps > inverse video in the status bar, perhaps alternating the two > representations?). > > Personally, I can read the Roman alphabet, accented or not, whether it > be English, German or whatever (I may not understand the language I am > reading though, but I can interpret the characters I see). I can't read > chinese, cryllic, arabic or any other non-latin script. So, for me, an > option to highlight non-latin IDN URLs would be a start because I would > have no interest in following such links. > > I realise that won't be a solution for many people but I guess it would > cover the majority of the people who would be the target of such a > spoofing scheme (i.e. those who primarily use the latin alphabet / ascii > character set). > > I don't know how this stuff works so I'll butt out now, glad to see it's > being tracked as an issue on Github. You mean in the status bar, where the current URL is shown? I had considered that, but I'm not sure it's obvious enough. If you don't know, is a, say, grey "apple.com" different from a green one? My current stance on this, by the way, is showing the Punycode representation in addition to the "normal" one for any non-ascii URL: https://github.com/qutebrowser/qutebrowser/issues/2547#issuecomment-295877408 Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 Mon Apr 24 07:25:42 2017 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 24 Apr 2017 07:25:42 +0200 Subject: [qutebrowser] IDN spoofing In-Reply-To: <20170420195104.2o4vk4tf5s4td2ka@hooch.localdomain> References: <20170420042434.fldiy7zkm4lnjxde@hooch.localdomain> <2e3fc727-1ba8-7ce0-6ca6-a251755046ee@lane.uk.net> <20170420195104.2o4vk4tf5s4td2ka@hooch.localdomain> Message-ID: <20170424052541.ijjdradlq4b4u6ge@hooch.localdomain> Hey, On Thu, Apr 20, 2017 at 09:51:04PM +0200, Florian Bruhin wrote: > My current stance on this, by the way, is showing the Punycode > representation in addition to the "normal" one for any non-ascii URL: > https://github.com/qutebrowser/qutebrowser/issues/2547#issuecomment-295877408 This is what I ended up doing now: https://github.com/qutebrowser/qutebrowser/commit/195d0ea2074cd559c6f4b29cccff9022dbbe7658 Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 Apr 25 22:59:32 2017 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 25 Apr 2017 22:59:32 +0200 Subject: [qutebrowser] Contributing to qutebrowser in C++/JavaScript Message-ID: <20170425205932.6ewxhhipmfjoxidh@hooch.localdomain> Hey, just a small heads-up for people who'd like to contribute things to qutebrowser but prefer C++ or JavaScript to Python - I've now labelled some issues involving those languages: C++: https://github.com/qutebrowser/qutebrowser/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Ac%2B%2B JavaScript: https://github.com/qutebrowser/qutebrowser/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Ajavascript Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 trevor.robertson55 at gmail.com Thu Apr 27 11:35:30 2017 From: trevor.robertson55 at gmail.com (Trevor Robertson) Date: Thu, 27 Apr 2017 11:35:30 +0200 Subject: [qutebrowser] Which manjaro distro = best for qutebrowser? Message-ID: Hi thanks again, your app is still my favourite. It works great in Windows 10. (You can ignore the email I sent from rocky.hillside7 at gmail.com = the one I use on my phone, I forgot about the membership thing.) Qutebrowser crashed a few times in manjaro i3 edition community edition - I sent a report - but don't worry too much. It is an old laptop that I installed this on. If there is a different manjaro distro that you think should give the least problems that I will rather just try that one instead. (I like using the keyboard and the idea of the i3 tiling manager but the non-i3 manjaros might be more customisable anyway with regard to the keyboard.) -> Say I install one of the mainstream manjaros: Which desktop environment should I choose? I really appreciate the help! Wonderful browser and does everything I want. Once my linux is going well I will be able to implement your spawn to media player idea also for fullscreen youtube. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Apr 27 22:59:31 2017 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 27 Apr 2017 22:59:31 +0200 Subject: [qutebrowser] Which manjaro distro = best for qutebrowser? In-Reply-To: References: Message-ID: <20170427205930.ekh63g3smdpacr3j@hooch.localdomain> Hey Trevor, On Thu, Apr 27, 2017 at 11:35:30AM +0200, Trevor Robertson wrote: > (You can ignore the email I sent from rocky.hillside7 at gmail.com = the one I > use on my phone, I forgot about the membership thing.) FWIW I added that to the whitelist now, so you'll be able to send mails from there too. > Qutebrowser crashed a few times in manjaro i3 edition community edition - I > sent a report - but don't worry too much. It is an old laptop that I > installed this on. > > If there is a different manjaro distro that you think should give the least > problems that I will rather just try that one instead. (I like using the > keyboard and the idea of the i3 tiling manager but the non-i3 manjaros > might be more customisable anyway with regard to the keyboard.) > > -> Say I install one of the mainstream manjaros: Which desktop environment > should I choose? Which DE you use shouldn't affect qutebrowser much. What's more important is that you either install qt5-webkit-ng, or install qt5-webengine and start with "--backend webengine". Some features (most notably private browsing) are still missing, but qutebrowser will likely be running much more stable. Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) 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 lgdeluca84 at gmail.com Thu Apr 27 23:08:14 2017 From: lgdeluca84 at gmail.com (Leo .) Date: Thu, 27 Apr 2017 16:08:14 -0500 Subject: [qutebrowser] Which manjaro distro = best for qutebrowser? In-Reply-To: <20170427205930.ekh63g3smdpacr3j@hooch.localdomain> References: <20170427205930.ekh63g3smdpacr3j@hooch.localdomain> Message-ID: On Thu, Apr 27, 2017 at 3:59 PM, Florian Bruhin wrote: > Some features > (most notably private browsing) are still missing ?I like using Firejail with Qutebrowser. It kind of works as private browsing for me.? -------------- next part -------------- An HTML attachment was scrubbed... URL: