From javierayres at gmail.com Wed Mar 6 02:58:46 2019 From: javierayres at gmail.com (Javier Ayres) Date: Tue, 5 Mar 2019 22:58:46 -0300 Subject: [qutebrowser] Multi web engine support in the future Message-ID: Hi everyone. With the ongoing work happening as part of the research project and the idea of dropping support for QtWebKit, I'm wondering what is the plan for the future of qutebrowser regarding the support of multiple web engines. Are you planning to make qutebrowser a QtWebEngine-exclusive browser or are you going to maintain/improve the existing abstraction layer that exists between qutebrowser and the engine? Any thoughts on adding support for another specific web engine? Thanks. From jaygkamat at gmail.com Wed Mar 6 03:41:41 2019 From: jaygkamat at gmail.com (Jay Kamat) Date: Tue, 05 Mar 2019 18:41:41 -0800 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: References: Message-ID: <87h8cgzpui.fsf@eve> Javier Ayres writes: > With the ongoing work happening as part of the research project and > the idea of dropping support for QtWebKit, I'm wondering what is the > plan for the future of qutebrowser regarding the support of multiple > web engines. Most likely, the abstract base classes will continue to exist even if one engine's support is dropped, but there will be less incentive to maintain them. It would probably be more effort to merge everything back together (with little gain). I also think that the maintenance burden of QtWebKit is not that high. In many cases, I found bugs in patches I submitted by running them against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa, so to me, even if no one uses QtWebKit it remains useful. > Are you planning to make qutebrowser a QtWebEngine-exclusive browser or are > you going to maintain/improve the existing abstraction layer that exists > between qutebrowser and the engine? Any thoughts on adding support for > another specific web engine? The multiple backend approach works because there are multiple backends supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding support for another engine would be pretty difficult as you would need to integrate it into both qt (and PyQt5). I think it would be extremely difficult to add support for a renderer not integrated into qt, as qutebrowser is heavily dependent on qt for many things. It would probably be easier to just update QtWebKit to use a newer version of WebKit. -Jay From me at the-compiler.org Wed Mar 6 13:25:46 2019 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 6 Mar 2019 13:25:46 +0100 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: <87h8cgzpui.fsf@eve> Message-ID: <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> Hi, On Tue, Mar 05, 2019 at 10:58:46PM -0300, Javier Ayres wrote: > With the ongoing work happening as part of the research project and > the idea of dropping support for QtWebKit, I'm wondering what is the > plan for the future of qutebrowser regarding the support of multiple > web engines. Are you planning to make qutebrowser a > QtWebEngine-exclusive browser or are you going to maintain/improve the > existing abstraction layer that exists between qutebrowser and the > engine? Any thoughts on adding support for another specific web > engine? I don't really have a definitive answer on this. I do want to simplify things where possible - in places where such a change would increase maintainability and reduce complexity, I will (over time) merge "abstract" code with QtWebEngine-specific code, or be less strict about introducing QtWebEngine-specific things. As long as there isn't another possible backend on the horizon, I think that's the right thing to do - if there's ever another backend introduced, the abstractions used for QtWebKit/QtWebEngine might need some larger adjustments anyways. In short, there's no point in things being more complex than they have to be, and I do think complexity/maintainability is a rather big issue at the moment. I'd rather have things a bit simpler, and removing QtWebKit support will be a big step in that direction (moving things from the core to extensions is another big one). As for specific web engines: There are only three active engines I can think of: - WebKitGTK - obviously not integrated with Qt. QtWebKit tries to do so, but I don't see that going anywhere in the future. Some company with enough resources would need to pick it up, and seeing that hasn't happened since Qt removed it three years ago, I doubt it ever will. - Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with Qt integration[4], so the only one which would be reasonably possible to integrate with qutebrowser. However, I don't see much benefit over QtWebEngine, seeing that both are based on Chromium, and I'm not aware of any killer features (like Chromium extension support) which would be a good reason to look into it. - Servo[5] - support for it would be amazing (and it'd be a real alternative to QtWebEngine), but the whole ecosystem isn't there yet. Embedding it into an existing project isn't really supported well (though there's some community effort like [6] and [7]). Also, someone would need to write Rust <-> Python bindings for it, and find out how to integrate those into Qt. That someone hasn't appeared so far, and it likely won't be me. ;-) [1] https://bitbucket.org/chromiumembedded/cef [2] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework [3] https://github.com/cztomczak/cefpython [4] https://github.com/cztomczak/cefpython/blob/master/examples/qt.py [5] https://github.com/servo/servo [6] https://github.com/paulrouget/servo-embedding-example [7] https://github.com/paulrouget/servo-embedding-api On Tue, Mar 05, 2019 at 06:41:41PM -0800, Jay Kamat wrote: > > Javier Ayres writes: > > > With the ongoing work happening as part of the research project and > > the idea of dropping support for QtWebKit, I'm wondering what is the > > plan for the future of qutebrowser regarding the support of multiple > > web engines. > > Most likely, the abstract base classes will continue to exist even if one > engine's support is dropped, but there will be less incentive to maintain > them. It would probably be more effort to merge everything back together (with > little gain). I also think that the maintenance burden of QtWebKit is not that > high. I agree it's not a high burden, but there are a lot of smaller things: - It *is* additional work for major features or refactorings. The last things I remember were Greasemonkey support (though some of that was also needed for QtWebEngine with Qt 5.7, but support for that is going away as well), and my PDF.js rewrite. - It does introduce a lot of additional complexity. Both in code which is lying around but rarely used/tested (like file listing support for QtWebKit, or mthml downloads, or many other things QtWebEngine does natively), and in complexity. I do like some of those abstractions (the tab API proved to be a great idea, for example), but in other places, I really don't like how complex and entangled things have gotten. - It does introduce an additional burden for any changes, because you'll need to test on QtWebKit as well (and/or maintain the CI infrastructure to do so), and it is often additional work for contributors. > In many cases, I found bugs in patches I submitted by running them > against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa, > so to me, even if no one uses QtWebKit it remains useful. Do you have examples for that? > > Are you planning to make qutebrowser a QtWebEngine-exclusive browser or are > > you going to maintain/improve the existing abstraction layer that exists > > between qutebrowser and the engine? Any thoughts on adding support for > > another specific web engine? > > The multiple backend approach works because there are multiple backends > supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding > support for another engine would be pretty difficult as you would need to > integrate it into both qt (and PyQt5). > > I think it would be extremely difficult to add support for a renderer not > integrated into qt, as qutebrowser is heavily dependent on qt for many things. If you check the CEF example[4] it's actually not that bad - in brief: - Integrate the renderer's main loop with Qt (or configure it to run it its own thread, like I think done there). - Get the renderer to render into your window, by giving it a low-level window handle like in that example, or by providing it with an OpenGL thingy (surface?) to render on (which is what QtWebEngine does with Chromium, I think). - Dispatch some events like the window being moved/resized to the renderer. - Depending how things are implemented, dispatch input events as well, if Qt is getting them instead of the renderer (doesn't seem to be necessary in the CEF example). > It would probably be easier to just update QtWebKit to use a newer version of > WebKit. I doubt it. Doing that is not something a single developer is able to do, as we saw with QtWebKit. Annulen isn't the only one who seems to have given up either: https://github.com/annulen/webkit/issues/775 Like said above, I don't have any hopes of it happening without a company picking it up (which doesn't seem to be happening either). Phew, that was a long mail, without a clear answer. :-) 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 javierayres at gmail.com Wed Mar 6 17:29:03 2019 From: javierayres at gmail.com (Javier Ayres) Date: Wed, 6 Mar 2019 13:29:03 -0300 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> References: <87h8cgzpui.fsf@eve> <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> Message-ID: Thanks for the responses guys. It makes a lot of sense that you don't have a definitive answer (although your expectations seem to go off in opposite directions :D) given that this highly depends on the availability of external projects. I would love to see servo working with qutebrowser (once it is stable, which I think is far from) or even gecko but I agree that maintaining an abstraction layer just in case that ever happens is wasted effort. > It would probably be easier to just update QtWebKit to use a newer version of > WebKit. Agreed, but as Florian says, it is still a monumental task. I do think that is still easier than coming up with a whole new qt integration with another engine from scratch. Also thanks for the links to related projects. I've been toying with the idea of writing something like that but failed to find enough documentation to even get started. On Wed, Mar 6, 2019, 09:25 Florian Bruhin wrote: > Hi, > > On Tue, Mar 05, 2019 at 10:58:46PM -0300, Javier Ayres wrote: > > With the ongoing work happening as part of the research project and > > the idea of dropping support for QtWebKit, I'm wondering what is the > > plan for the future of qutebrowser regarding the support of multiple > > web engines. Are you planning to make qutebrowser a > > QtWebEngine-exclusive browser or are you going to maintain/improve the > > existing abstraction layer that exists between qutebrowser and the > > engine? Any thoughts on adding support for another specific web > > engine? > > I don't really have a definitive answer on this. I do want to simplify > things where possible - in places where such a change would increase > maintainability and reduce complexity, I will (over time) merge > "abstract" code with QtWebEngine-specific code, or be less strict about > introducing QtWebEngine-specific things. > > As long as there isn't another possible backend on the horizon, I think > that's the right thing to do - if there's ever another backend > introduced, the abstractions used for QtWebKit/QtWebEngine might need > some larger adjustments anyways. > > In short, there's no point in things being more complex than they have > to be, and I do think complexity/maintainability is a rather big issue > at the moment. I'd rather have things a bit simpler, and removing > QtWebKit support will be a big step in that direction (moving things > from the core to extensions is another big one). > > As for specific web engines: There are only three active engines I can > think of: > > - WebKitGTK - obviously not integrated with Qt. QtWebKit tries to do > so, but I don't see that going anywhere in the future. Some company > with enough resources would need to pick it up, and seeing that hasn't > happened since Qt removed it three years ago, I doubt it ever will. > > - Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with > Qt integration[4], so the only one which would be reasonably possible > to integrate with qutebrowser. However, I don't see much benefit over > QtWebEngine, seeing that both are based on Chromium, and I'm not aware > of any killer features (like Chromium extension support) which would > be a good reason to look into it. > > - Servo[5] - support for it would be amazing (and it'd be a real > alternative to QtWebEngine), but the whole ecosystem isn't there yet. > Embedding it into an existing project isn't really supported well > (though there's some community effort like [6] and [7]). Also, > someone would need to write Rust <-> Python bindings for it, and find > out how to integrate those into Qt. That someone hasn't appeared so > far, and it likely won't be me. ;-) > > [1] https://bitbucket.org/chromiumembedded/cef > [2] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework > [3] https://github.com/cztomczak/cefpython > [4] https://github.com/cztomczak/cefpython/blob/master/examples/qt.py > [5] https://github.com/servo/servo > [6] https://github.com/paulrouget/servo-embedding-example > [7] https://github.com/paulrouget/servo-embedding-api > > On Tue, Mar 05, 2019 at 06:41:41PM -0800, Jay Kamat wrote: > > > > Javier Ayres writes: > > > > > With the ongoing work happening as part of the research project and > > > the idea of dropping support for QtWebKit, I'm wondering what is the > > > plan for the future of qutebrowser regarding the support of multiple > > > web engines. > > > > Most likely, the abstract base classes will continue to exist even if one > > engine's support is dropped, but there will be less incentive to maintain > > them. It would probably be more effort to merge everything back together > (with > > little gain). I also think that the maintenance burden of QtWebKit is > not that > > high. > > I agree it's not a high burden, but there are a lot of smaller things: > > - It *is* additional work for major features or refactorings. The last > things I remember were Greasemonkey support (though some of that was > also needed for QtWebEngine with Qt 5.7, but support for that is going > away as well), and my PDF.js rewrite. > > - It does introduce a lot of additional complexity. Both in code which > is lying around but rarely used/tested (like file listing support for > QtWebKit, or mthml downloads, or many other things QtWebEngine does > natively), and in complexity. I do like some of those abstractions > (the tab API proved to be a great idea, for example), but in other > places, I really don't like how complex and entangled things have > gotten. > > - It does introduce an additional burden for any changes, because you'll > need to test on QtWebKit as well (and/or maintain the CI > infrastructure to do so), and it is often additional work for > contributors. > > > In many cases, I found bugs in patches I submitted by running them > > against QtWebKit (that affected QtWebEngine in subtler ways) and vice > versa, > > so to me, even if no one uses QtWebKit it remains useful. > > Do you have examples for that? > > > > Are you planning to make qutebrowser a QtWebEngine-exclusive browser > or are > > > you going to maintain/improve the existing abstraction layer that > exists > > > between qutebrowser and the engine? Any thoughts on adding support for > > > another specific web engine? > > > > The multiple backend approach works because there are multiple backends > > supported through similar (and in some cases, the same) PyQt5/Qt apis. > Adding > > support for another engine would be pretty difficult as you would need to > > integrate it into both qt (and PyQt5). > > > > I think it would be extremely difficult to add support for a renderer not > > integrated into qt, as qutebrowser is heavily dependent on qt for many > things. > > If you check the CEF example[4] it's actually not that bad - in brief: > > - Integrate the renderer's main loop with Qt (or configure it to run it > its own thread, like I think done there). > > - Get the renderer to render into your window, by giving it a low-level > window handle like in that example, or by providing it with an OpenGL > thingy (surface?) to render on (which is what QtWebEngine does with > Chromium, I think). > > - Dispatch some events like the window being moved/resized to the > renderer. > > - Depending how things are implemented, dispatch input events as well, > if Qt is getting them instead of the renderer (doesn't seem to be > necessary in the CEF example). > > > It would probably be easier to just update QtWebKit to use a newer > version of > > WebKit. > > I doubt it. Doing that is not something a single developer is able to > do, as we saw with QtWebKit. Annulen isn't the only one who seems to > have given up either: https://github.com/annulen/webkit/issues/775 > Like said above, I don't have any hopes of it happening without a > company picking it up (which doesn't seem to be happening either). > > Phew, that was a long mail, without a clear answer. :-) > > 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 -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Mar 6 18:54:25 2019 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 6 Mar 2019 18:54:25 +0100 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: References: <87h8cgzpui.fsf@eve> <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> Message-ID: <20190306175425.rbhhyf2rk5xbsn4x@hooch.localdomain> Hi, On Wed, Mar 06, 2019 at 01:29:03PM -0300, Javier Ayres wrote: > I would love to see servo working with qutebrowser (once it is stable, > which I think is far from) or even gecko Gecko is pretty much unusable outside of Firefox AFAIK - I'm not aware of any projects using it as a standalone engine, and even projects which kind-of did (Conkeror[1] using Firefox' xulrunner) died when Mozilla deprecated that. [1] http://conkeror.org/ [2] https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XULRunner > Also thanks for the links to related projects. I've been toying with the > idea of writing something like that but failed to find enough documentation > to even get started. FWIW there's also a project which tried to write a vim-like browser using servo, but it seems to have died quickly: https://github.com/meh/miserve 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 jaygkamat at gmail.com Wed Mar 6 23:07:31 2019 From: jaygkamat at gmail.com (Jay Kamat) Date: Wed, 06 Mar 2019 14:07:31 -0800 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> References: <87h8cgzpui.fsf@eve> <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> Message-ID: <86o96nlkrg.fsf@gmail.com> Florian Bruhin writes: > - Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with > Qt integration[4], so the only one which would be reasonably possible > to integrate with qutebrowser. However, I don't see much benefit over > QtWebEngine, seeing that both are based on Chromium, and I'm not aware > of any killer features (like Chromium extension support) which would > be a good reason to look into it. One killer feature would be avoiding qtwebengine bugs (if cef is any better). Currently, the qtwebengine backend is about as painful to use as qtwebkit for me (and trending worse, ever since qt 5.7). I don't think cef is in any repos though, so it's probably not practical for most people. >> In many cases, I found bugs in patches I submitted by running them >> against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa, >> so to me, even if no one uses QtWebKit it remains useful. > > Do you have examples for that? I find that qtwebkit is more aggressive on cleaning up resources on the C side. Running a trivial manual/automated test in qtwebkit for a behavior often exposes use-after-free bugs. The most recent one is this commit: https://github.com/qutebrowser/qutebrowser/pull/4498/commits/128d17fe91db7fb1819d741c0aab072934abb3bb Of course, there are other cases as well, I've seen qtwebkit tests catch other random bugs (which were bugs on the webengine side too but untested or flakey). >> The multiple backend approach works because there are multiple backends >> supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding >> support for another engine would be pretty difficult as you would need to >> integrate it into both qt (and PyQt5). >> >> I think it would be extremely difficult to add support for a renderer not >> integrated into qt, as qutebrowser is heavily dependent on qt for many things. > > If you check the CEF example[4] it's actually not that bad - in brief: > > - Integrate the renderer's main loop with Qt (or configure it to run it > its own thread, like I think done there). > > - Get the renderer to render into your window, by giving it a low-level > window handle like in that example, or by providing it with an OpenGL > thingy (surface?) to render on (which is what QtWebEngine does with > Chromium, I think). > > - Dispatch some events like the window being moved/resized to the > renderer. > > - Depending how things are implemented, dispatch input events as well, > if Qt is getting them instead of the renderer (doesn't seem to be > necessary in the CEF example). I don't think that's necessarily the hard part. The hard part is syncing up the entire API so everything works seamlessly. Since the QtWebEngine/WebKit apis are large, this isn't trivial. That looks like a bare minimum implementation, but for proper integration into qutebrowser there are many more APIs that need to be exposed for everything to work as expected. > >> It would probably be easier to just update QtWebKit to use a newer version of >> WebKit. > > I doubt it. Doing that is not something a single developer is able to > do, as we saw with QtWebKit. Annulen isn't the only one who seems to > have given up either: https://github.com/annulen/webkit/issues/775 > Like said above, I don't have any hopes of it happening without a > company picking it up (which doesn't seem to be happening either). Updating QtWebKit must be easier because it's the exact same task (porting webkitgtk or plain webkit to qt) with a huge advantage - it already has a working example on an older version. (non chromium) browser engines don't have that advantage. There are several browser wrappers floating out there that are maintained by small groups - see this project for an example. The problem is that no one cares enough to maintain qtwebkit at the moment, not that it's a monumental/impossible task. https://github.com/zserge/webview In some ways, qtwebengine is maintained even worse than qtwebkit, as it has multiple bugs which have never been present in qtwebkit, and it is struggling to add features which have been present in webkit for a long time. https://bugreports.qt.io/browse/QTBUG-65223 https://bugreports.qt.io/browse/QTBUG-67434 https://bugreports.qt.io/browse/QTBUG-51192 https://bugreports.qt.io/browse/QTBUG-50995 (although this is hopefully done) https://bugreports.qt.io/browse/QTBUG-62957 https://bugreports.qt.io/browse/QTBUG-51772 https://bugreports.qt.io/browse/QTBUG-68224 (fixed, but really!) - Lack of a 'DomContentLoaded' signal on the cpp side - White flashes on page load (seems to be getting worse every release) From me at the-compiler.org Thu Mar 7 09:21:23 2019 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 7 Mar 2019 09:21:23 +0100 Subject: [qutebrowser] Multi web engine support in the future In-Reply-To: <86o96nlkrg.fsf@gmail.com> References: <87h8cgzpui.fsf@eve> <20190306122546.wrpymlgdj6yxcqgh@hooch.localdomain> <86o96nlkrg.fsf@gmail.com> Message-ID: <20190307082123.qooecua5sr2qb5tr@hooch.localdomain> Hey, On Wed, Mar 06, 2019 at 02:07:31PM -0800, Jay Kamat wrote: > > Florian Bruhin writes: > > > - Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with > > Qt integration[4], so the only one which would be reasonably possible > > to integrate with qutebrowser. However, I don't see much benefit over > > QtWebEngine, seeing that both are based on Chromium, and I'm not aware > > of any killer features (like Chromium extension support) which would > > be a good reason to look into it. > > One killer feature would be avoiding qtwebengine bugs (if cef is any better). I can't say I've tried, but I have my doubts that it is. Certainly not to the point (IMHO) that it'd be worth the effort. > I don't think cef is in any repos though, so it's probably not > practical for most people. Yeah, that was one big reason that I've never looked at it in detail. I think the idea is that you bundle it with your application (like e.g. Steam does) and compile it from source. There aren't even any official builds (though Spotify provides[1] unofficial ones). [1] http://opensource.spotify.com/cefbuilds/index.html > >> In many cases, I found bugs in patches I submitted by running them > >> against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa, > >> so to me, even if no one uses QtWebKit it remains useful. > > > > Do you have examples for that? > > I find that qtwebkit is more aggressive on cleaning up resources on the C > side. Running a trivial manual/automated test in qtwebkit for a behavior often > exposes use-after-free bugs. > > The most recent one is this commit: > > https://github.com/qutebrowser/qutebrowser/pull/4498/commits/128d17fe91db7fb1819d741c0aab072934abb3bb > > Of course, there are other cases as well, I've seen qtwebkit tests catch other > random bugs (which were bugs on the webengine side too but untested or > flakey). Fair point - that indeed sounds useful to have, but probably still not useful enough for me to want to continue maintaining QtWebKit support (even more so with Qt/PyQt 6 on the horizon, where I bet things will get real painful) :-/ > >> The multiple backend approach works because there are multiple backends > >> supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding > >> support for another engine would be pretty difficult as you would need to > >> integrate it into both qt (and PyQt5). > >> > >> I think it would be extremely difficult to add support for a renderer not > >> integrated into qt, as qutebrowser is heavily dependent on qt for many things. > > > > If you check the CEF example[4] it's actually not that bad - in brief: > > > > - Integrate the renderer's main loop with Qt (or configure it to run it > > its own thread, like I think done there). > > > > - Get the renderer to render into your window, by giving it a low-level > > window handle like in that example, or by providing it with an OpenGL > > thingy (surface?) to render on (which is what QtWebEngine does with > > Chromium, I think). > > > > - Dispatch some events like the window being moved/resized to the > > renderer. > > > > - Depending how things are implemented, dispatch input events as well, > > if Qt is getting them instead of the renderer (doesn't seem to be > > necessary in the CEF example). > > I don't think that's necessarily the hard part. The hard part is syncing up > the entire API so everything works seamlessly. Since the QtWebEngine/WebKit > apis are large, this isn't trivial. That looks like a bare minimum > implementation, but for proper integration into qutebrowser there are many > more APIs that need to be exposed for everything to work as expected. Whatever renderer we're talking about would already expose those APIs, right? So there are "only" two things to consider: - Making that API usable from Python via bindings (those already exist for CEF, but no idea how tricky it'd be to bind Rust for Servo). - Using the Python API inside qutebrowser - I don't see a big difference between a Qt renderer and one independent from Qt here. Sure, you might need to convert e.g. URLs from whatever URL type it uses to QUrl, but that shouldn't be too big, compared to the work adding a new renderer takes anyways. > >> It would probably be easier to just update QtWebKit to use a newer version of > >> WebKit. > > > > I doubt it. Doing that is not something a single developer is able to > > do, as we saw with QtWebKit. Annulen isn't the only one who seems to > > have given up either: https://github.com/annulen/webkit/issues/775 > > Like said above, I don't have any hopes of it happening without a > > company picking it up (which doesn't seem to be happening either). > > Updating QtWebKit must be easier because it's the exact same task (porting > webkitgtk or plain webkit to qt) with a huge advantage - it already has a > working example on an older version. (non chromium) browser engines don't have > that advantage. True - however, note that Qt primarely abandoned WebKit because it was unmaintable (and I don't blame them). I've been watching QtWebKit (and later QtWebEngine) development pretty much since the beginning of 2014, and it became more and more apparent that they struggled to keep it up-to-date (it diverged from upstream WebKit for quite a bit before they decided to abandon it). > There are several browser wrappers floating out there that are maintained by > small groups - see this project for an example. The problem is that no one > cares enough to maintain qtwebkit at the moment, not that it's a > monumental/impossible task. > > https://github.com/zserge/webview You're comparing apples to oranges. That project (and other small ones) are wildly different from something like QtWebKit, for two reasons: - They just wrap existing abstractions which provide a stable API - in case of that project, they even use WebKitGTK on Linux. - They only provide a very shallow API - not much more than loading a page and injecting JS into it. That project is more comparable to webkittab.py/webenginetab.py in qutebrowser. It's also quite small - 2265 lines of C (in a single header file...) plus 572 lines with (hand-written) bindings to Go. Things like QtWebKit/QtWebEngine/CEF/... are vastly bigger, exposing a bigger API. They also need to patch the upstream sources because upstream usually doesn't care much about them, and they need to keep up-to-date with a crazy amount of changes (and changing APIs). We're talking millions of changed lines with each Chromium update - IIRC, one talk about QtWebEngine I watched said they spend around a man-month or two each Qt release just for the Chromium upgrade. I don't think things are looking any different with WebKit. For a while, things apparently looked good with QtWebKit being a part of upstream WebKit, but that changed mid-2013 when they were removed from there and became a downstream port (forking the whole WebKit project - essentially what QtWebEngine does with Chromium because Google doesn't care about third-party projects). Ever since, QtWebKit was lagging behind upstream WebKit, usually by some years. I guess it was okay when I started qutebrowser and they still were able to keep up with upstream, but it only got worse, even before QtWebKit was officially deprecated. I'm not sure how things are looking for CEF, but I doubt it's much different. If it's any indication, I see builds since February based on Chromium 72. Qt currently is at 71, working on 72 and 73[2][3] (Chromium 72 is current, while 73 while be released in a few days[4]) [2] https://codereview.qt-project.org/#/q/branch:upstream-master+project:qt/qtwebengine-chromium,n,z [3] https://codereview.qt-project.org/#/q/message:Adaptations+project:qt/qtwebengine,n,z [4] https://www.chromium.org/developers/calendar > In some ways, qtwebengine is maintained even worse than qtwebkit It depends on how strongly you care about "does it keep up-to-date with upstream changes, especially security fixes". I care a lot - if you use something other than Qt 5.9 LTS/5.12, or if you use QtWebKit, you don't care at all (or your distribution doesn't, hi Debian stable!). If you don't care at all, maintaining suddenly gets a lot easier, because you suddenly have a stable API (if you never update from upstream) and some months of developer-time to spend. It also means you'll be full of security issues, and run into compatibility issues a few months to years down the road (see: GitHub being broken with QtWebKit). Fortunately, QtWebEngine developers do care. ;-) > as it has multiple bugs which have never been present in qtwebkit Contrary to QtWebKit, it doesn't segfault/freeze all the time. > and it is struggling to add features which have been present in webkit > for a long time. For some of those (say, deeper network integration like with QNetworkAccessManager, or a web element API for C++/Python, or the user style sheet thing you linked), that's by design. If those aren't doable with the API they get upstream from Chromium, implementing those would cause the Chromium fork to diverge more from upstream, causing another QtWebKit-like situation: A thing nobody wants to (or possibly can) maintain anymore. QtWebEngine saying "no" to those features is a good thing. I'd take me writing some JS over QtWebEngine turning into an unmaintainable mess any day, and I don't like JS. Our best bet is waiting for some of Chromium's extension API to be supported - it's also quite a maintenance burden for QtWebEngine most likely, but it enables so many things that it seems to be worth it from them, from what I've seen so far. As for other things (like notifications): Yeah - I'm not too happy about how long things take, but that's how things are. Qt has multiple (I'd say five or so?) people working full-time on QtWebEngine, and a lot of the time they're busy with running after Chromium upstream. That leaves little time for new features. Pretty much the contrary - every major new feature will mean slightly more time spent on Chromium updates in the future. I can't say I'm happy with the situation, but there's really no one to blame. QtWebEngine-developers are doing great work (and most of it is rather invisible, it seems), and The Qt Company can't really be blamed for not hiring more people for QtWebEngine either (their main focus also probably isn't a real web browser, but a web rendering component, similar to how CEF is usually used). If anything, I'd blame Google for not caring more about third-party projects like CEF/QtWebEngine. If they'd make Chromium usable as a library with a stable API, a lot would improve (and it'd probably make it possible to upgrade Chromium separately from QtWebEngine). Then again, it'd probably make things easier for Brave/Vivaldi/Opera/... as well, and I guess Google isn't interested in that :D I had high hopes for Servo there, but apparently embedders isn't what Mozilla is after either. I'm not actually sure what the goal of Servo is, as replacing Firefox isn't either. Probably to serve as a research project for ideas which might later land in Firefox (like it happened with Stylo, the component handling CSS). I guess if it's that, having a stable API for embedders is also pretty much against their goals, because experimenting and stability usually don't mix. Maybe CEF has more manpower (at least some big companies are using it), but again, I doubt things are looking much different there. One person alone doing all that maintenance work in their spare time just isn't going to happen. > https://bugreports.qt.io/browse/QTBUG-51772 > - White flashes on page load (seems to be getting worse every release) At least those two are present in Chromium as well, IIRC. I agree some of the others are/were quite frustrating... Living up to the "email is not SMS" link in my signature, 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 Mar 18 15:02:48 2019 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 18 Mar 2019 15:02:48 +0100 Subject: [qutebrowser] Roadmap for 2019 and state of extensions Message-ID: <20190318140248.rtxkeeqt6cdqil7n@hooch.localdomain> Heya! I've wanted to write this mail for a while, but for a long time it wasn't exactly clear what my bachelor thesis is going to be about, and then I also caught a bad flu last week - but now everything is more or less back to normal! \o/ I figured it's about time that I have something nice to link to when asked for my current plans on qutebrowser, and I've also been asked about how things look for extensions and that research project - so without further ado: ---------- The research project on qutebrowser extensions was quite a success from the academic perspective - I'm happy with how the documentation turned out[1], and I ended up getting a (Swiss) 5.5 for it, which is basically equivalent to a 90% (with possible 10% increments), so I can't complain! [1] https://github.com/qutebrowser/qutebrowser-hsr-sa/releases/download/final/sa.pdf However, the focus on actual code was relatively small - out of a total of 237 hours spent on the project, only about 60 hours actually were spent on implementation, which included introducing the mypy type checker to qutebrowser's codebase/CI. It resulted in a basic extension API which is used inside qutebrowser for various functionality (such as its adblocker), but that API isn't open to "real" extensions yet, and a lot of things aren't possible yet. ---------- Originally it was planned to continue working on it with the same advisor as a bachelor thesis. However, we ended up getting another advisor for $reasons, who preferred to push his own project (a hex editor showing files in a structured way, think wireshark but for files) instead. When in week 3 or so, I found out that there's an existing project which pretty much does what we were supposed to do[2], so we decided to find a new topic. [2] https://www.synalysis.net/ and https://hexinator.com/ Also, Wireshark can open e.g. ELF files as well! Back on square one, I was pretty much free in selecting a topic. However, I realized I don't really want to continue working on qutebrowser extensions for my bachelor thesis, for a variety of reasons. I really wanted to do something different for once, but the main reason was how the PR situation is looking currently: Given that time was pretty tight already, it wasn't possible to take care of open pull requests - I'd have to continue refactoring things and ignoring (~60) open PRs, which was already quite troublesome with the existing research project. Given that pretty much nobody cared about my notice to hold back contributions, I'm forced to spend time on a lot of things other than extensions while not really having the time to do so (and doing so outside of the bachelor thesis means I spend pretty much all my time on qutebrowser, I'd really like to do something other than that as well). Instead, I decided to propose a different topic tangentially related to qutebrowser: Writing a crash report server which can collect/categorize (qutebrowser) crash reports, and integrates something like a ticket system - in short, I want to be able to easily read and answer to crash reports I get. Currently, those are sent to a pastebin and I handle them manually, which worked out when there was around one report per day - but with qutebrowser getting more popular, I'm also seeing more crash reports coming in, with almost 1000 unread ones. Some automation should help me to take care of that, make my life simpler with future crash reports, and also is a nice topic for a bachelor thesis which isn't just "more work on qutebrowser extensions". ---------- As for what happened in 2019 so far: I've been quite busy with fixes for Qt 5.12 and then releasing v1.6.0. Over the next few days (as soon as a new PyQt release is out), I'm also going to release v1.6.1. Until I'm handing in my bachelor thesis (mid-June), I'm going to be quite busy with that (and another course where we're writing a compiler, which is quite interesting, but also quite some work). The rest of the time will probably be spent with looking at lots and lots of pull requests - I don't really expect to have any time left to continue working on extensions besides that, I'm afraid. ---------- However, after mid-June, I'm almost finished with my studies (only one open-book exam remaining in August, C++ Advanced). My plans after that currently look as follows: - Work some 40% (i.e. 2 days a week) as an assistant at the university, likely helping out with some mixture of teaching Python, C and assembly :D - Found my own (one-man) company and doing occasional freelancing stuff (like giving trainings in companies about Python and especially pytest). I've been doing some things like that in parallel to the studies, with little revenue, so I wasn't forced to do bureucratic stuff - but it's probably about time to make it official! - The rest of the time (probably 2-3 days a week), work full-time on open source software based on donations - primarly qutebrowser! I plan to launch another crowdfunding, this time focused on recurring donations (Patreon/OpenCollective likely), with t-shirts and stuff again. That's the rough plan - depending on how things turn out financially, I'll be able to adapt, and at some point (say, 1-3 years later) I'll probably go back to finding a full-time job somewhere, and/or pursue a master's degree. With that plan, I'll (finally!) be able to spend a lot of time on qutebrowser again, while still having a life outside of qutebrowser-stuff as well. I also expect things to progress much faster than during the research project, because the primary focus is getting things done for qutebrowser, not writing a lot of documentation ;-) The crowdfunding campaign and the work I'll do initially will be focused around extensions - extending (hah!) the API, making loading third-party extensions possible, distribution of extensions (with some kind of extension store/"manager"), moving more code from the core into extensions, etc. Long story short: I'll soon have quite some time dedicated all around extensions - but it's going to take some time until I can start. ---------- tl;dr: Research project went good, extensions aren't where I'd like them to be yet, until mid-June there likely won't be any work on extensions, but after that I hope to dedicate a couple of days per week to it! 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 Wed Mar 20 08:13:31 2019 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 20 Mar 2019 08:13:31 +0100 Subject: [qutebrowser] qutebrowser v1.6.1 released Message-ID: <20190320071331.dijmj2jbtsp2m5nh@hooch.localdomain> Hey! Apparently the GitHub API hates me today and I had to upload the Windows files by hand, but I'm still happy to announce that I just released v1.6.1. There are some little bugfixes, but the most important thing is that Windows/macOS releases ship an updated Qt with security fixes. Changed ~~~~~~~ - Windows/macOS releases now ship with Qt 5.12.2, which includes security fixes up to Chromium 72.0.3626.121 (including CVE-2019-5786 which is known to be exploited in the wild). Fixed ~~~~~ - Crash when using `:config-{dict,list}-{add,remove}` with an invalid setting. - Functionality like hinting on pages with an element with ID `_qutebrowser` (such as qutebrowser.org) on Qt 5.12. - The .desktop file in v1.6.0 was missing the "Actions" key, which is now fixed. - The SVG icon now has a size of 256x256px set to comply with freedesktop standards. - Setting `colors.statusbar.*.bg` to a gradient now has the expected effect of the gradient spanning the entire statusbar. 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 sdavies at umw.edu Wed Mar 20 15:57:57 2019 From: sdavies at umw.edu (Stephen Davies (sdavies)) Date: Wed, 20 Mar 2019 14:57:57 +0000 Subject: [qutebrowser] sorting bookmarks by recency Message-ID: <20190320145755.GA17942@umw.edu> The answer is probably staring me in the face, but I can't find it. When I go to qute://bookmarks, it displays all my quickmarks and bookmarks. However, the bookmarks seem to be alphabetized by page title. This is sometimes useful, but another useful thing is to be able to browse through what I've bookmarked "lately." Is there a way to sort the bookmarks by timestamp? - Stephen Davies, Ph.D. (stephen at umw.edu) From ryan at rcorre.net Wed Mar 20 17:16:14 2019 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Wed, 20 Mar 2019 12:16:14 -0400 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320145755.GA17942@umw.edu> References: <20190320145755.GA17942@umw.edu> Message-ID: <20190320161614.GC753@midova.localdomain> Hi Stephen, Bookmarks appear in the same order they appear in your bookmarks file. New bookmarks are appended to the end, so they will actually appear last. You can order the file however you like to change the order in the qutebrowser UI, but newly added bookmarks will always go to the end. For what its worth, I rarely notice the order as I tend to rely on text-filtering rather than scrolling. -Ryan On Wed 03/20/19 02:57PM, Stephen Davies (sdavies) wrote: > > The answer is probably staring me in the face, but I can't find it. > > When I go to qute://bookmarks, it displays all my quickmarks and bookmarks. > However, the bookmarks seem to be alphabetized by page title. This is sometimes > useful, but another useful thing is to be able to browse through what I've > bookmarked "lately." Is there a way to sort the bookmarks by timestamp? > > - Stephen Davies, Ph.D. > (stephen at umw.edu) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From me at the-compiler.org Wed Mar 20 17:35:38 2019 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 20 Mar 2019 17:35:38 +0100 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320161614.GC753@midova.localdomain> References: <20190320145755.GA17942@umw.edu> <20190320161614.GC753@midova.localdomain> Message-ID: <20190320163538.lavztct27obns4fq@hooch.localdomain> Hey, On Wed, Mar 20, 2019 at 12:16:14PM -0400, Ryan Roden-Corrent wrote: > Bookmarks appear in the same order they appear in your bookmarks file. > New bookmarks are appended to the end, so they will actually appear > last. You can order the file however you like to change the order in the > qutebrowser UI, but newly added bookmarks will always go to the end. > > For what its worth, I rarely notice the order as I tend to rely on > text-filtering rather than scrolling. That's true for the :open completion, but not for qute://bookmarks which Stephen was referring to - that page indeed sorts by title only: https://github.com/qutebrowser/qutebrowser/blob/v1.6.1/qutebrowser/browser/qutescheme.py#L178-L181 Ideally the page itself would allow changing the sort order interactively. I guess many of the qute:// pages could need some love - I opened an issue with some ideas: https://github.com/qutebrowser/qutebrowser/issues/4662 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 sdavies at umw.edu Wed Mar 20 18:14:17 2019 From: sdavies at umw.edu (Stephen Davies (sdavies)) Date: Wed, 20 Mar 2019 17:14:17 +0000 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320163538.lavztct27obns4fq@hooch.localdomain> References: <20190320145755.GA17942@umw.edu> <20190320161614.GC753@midova.localdomain> <20190320163538.lavztct27obns4fq@hooch.localdomain> Message-ID: <20190320171417.GD3735@umw.edu> Thanks to you both for your replies. Hey, as long as we're talking about dreamy enhancement requests, here's one that I'm sure would be very hard to implement, but which I think would be a killer feature. I'd love a way to search for text within "all pages that I've bookmarked." (So not just the title of the pages, but their text.) Don't know if it'd be easier to snapshot and store the text of every page as it's bookmarked, or to re-fetch the pages afresh whenever the user does the aforementioned kind of search. There are pros and cons to each, but either one would be a godsend. - Stephen Florian Bruhin wrote: > Hey, > > On Wed, Mar 20, 2019 at 12:16:14PM -0400, Ryan Roden-Corrent wrote: > > Bookmarks appear in the same order they appear in your bookmarks file. > > New bookmarks are appended to the end, so they will actually appear > > last. You can order the file however you like to change the order in the > > qutebrowser UI, but newly added bookmarks will always go to the end. > > > > For what its worth, I rarely notice the order as I tend to rely on > > text-filtering rather than scrolling. > > That's true for the :open completion, but not for qute://bookmarks which > Stephen was referring to - that page indeed sorts by title only: > > https://secure-web.cisco.com/1ea8RLb1TXmxzxV0AaAIcZKknrIOT8j5CsdSJ2mMo8IJMoTbElws85qMqhofkHwNb8QBRGKzkmwwW2362q8XnGxCY46Q7srYHgEpYdH7ZHnjAnNxbzXLlCt-DZk-BDZrOw8XYFWvS2PIM2bXzrJlhP-VHLBm2BUii_mPtOzG0Rp-jwWLf9No57GR_23NfFX0aBz40PGqIMpPxoEJ8sztBYEENM3hrNnPk9yajlx_htJxFNIYYFg8-HEfh-C7Fj3I2vLgMEeTBJ-GYaMr8b_vmqnLKvoQ6dIdpOsi9nGgdi0lpIVid0_dgDFg7QNX9vr9e-DfAx3NnFbvRn82XynMAkw/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fblob%2Fv1.6.1%2Fqutebrowser%2Fbrowser%2Fqutescheme.py#L178-L181 > > Ideally the page itself would allow changing the sort order interactively. I > guess many of the qute:// pages could need some love - I opened an issue with > some ideas: https://secure-web.cisco.com/1GSehjjHGWDpdtTqWydfDlh5Z0iNtR7ag7QFR32QhISaY0lQHvdZe72-TzCj-yzH2sTCzKAQd0zS3pcB78gUz-NmDEVXXWMANj9VXtCwZ2j2PJ_u9JO_9SjtcYiiz31WCG5_vspYr8ZCpxk1sLmugvdrwSxnFjvvIPTGkn6mvIAs9VJRSfPOf4-hiInVYA10EvDoUfcfpj4z1dhfyfWR58I7TGmhKzmoTwd8J1t7zq0MrvftTSzzN7HvJZ6EcUiKoDeLpLlNAna63ts3GbNAbNFYIwGYi5qfaKD823Vxd_GE2Mc2qfz_SW-oKrCRc2G9837p3ln3vK9DQHyrz7SWEmg/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fissues%2F4662 > > Florian > > -- > https://secure-web.cisco.com/1ZfjsCINYDU4PEppeN3EAeQtoK5r7Ibg4rZIQVlvAbq_A2l5u8duKgYpafWPXFYXwBAZFAmhlMgmoC_SA_4FDnorEKLZ43nFOtuHAe3asyq7lKtab5pJzgFoUtZasUYF1zUFM6MuNNWC7ngnWp5Fmux1gGK4DbeSWuqZ9o9CLWn4aApLIzA43KWNP9De9r8i1wvhsjY6KhYHdnv-LzSxPtkLgcIWdDcz2Fvjm-XdSCG1yqfsKPA69DScAMcqp0cxXOVaqspBUbw9l8ITp4e0If1vuBJqSTN-ZdwyvKtJ4-cq0Z6jLsdfYdEnAGGP3z7_qAEF7f1Jcu7x93HantXficg/https%3A%2F%2Fwww.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | https://secure-web.cisco.com/1eugnSH_hyEpLN1D1d9OuimhbXTRzVHHIJyEcnvZIX9bT9B7YL9U8XN726-Teqt2EH-H-BjvW1xFpAo-MJ3vLdoFrkgrZ_denRy-ZOJwc73rYsO9le8d6NNf5uWXONMNcmNsbtn0H_e2j9A_ywfzBfxFi5PFB3__Jgni4Nqwrn2rjym7pfUAkrkSd_Tp72rDTt4Ybahn1WzX8Z_ajvNmf-s6SL2GfXSOjS34a0vyWaIt3J-A-WmDH-C_3dWfEwNZub3vp61rRPgL1DlPooCfwpVbRfDB9FieTBOvDxAaGj7bh7rFwsrvSXL-G0qlSolR60XymaTzaBBtusPUOe5cNoA/https%3A%2F%2Fthe-compiler.org%2Fpubkey.asc > I love long mails! | https://secure-web.cisco.com/1JGNGBdKBO0dpCvng_NOODtQ5LuFmCDX0AquTeDQlFLdHRnFrM02y8oV24zADifxcITzujRtzdUzQIta3q4NYDB6qSP8dnPL646cxR5C2bgTQURCgyaWWuCYoCSfp5rIUxE5xm-jGykYzJRPp9eRIXtaQ6GKDbpR0MGBGkVma34pXQPd569eSfg2Np-onjubD2zlpmNDZGUk4M5OHkzfDeFUe0u_MoJMpEhxOsVsvvnRbP_lB6o9exAUWrWv8NCkDRve5l-55IDP4Ma18S7Tg5PeybPX7CAcl3vbi2jl2HUsZEZ44BZNspJOg712g0aoOagR-au96Yr8keHXUOtNxfw/https%3A%2F%2Femail.is-not-s.ms%2F From ryan at rcorre.net Wed Mar 20 18:53:05 2019 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Wed, 20 Mar 2019 13:53:05 -0400 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320171417.GD3735@umw.edu> References: <20190320145755.GA17942@umw.edu> <20190320161614.GC753@midova.localdomain> <20190320163538.lavztct27obns4fq@hooch.localdomain> <20190320171417.GD3735@umw.edu> Message-ID: <20190320175305.GG753@midova.localdomain> This sounds like a very specialized use-case for qutebrowser, but relatively straightforward using `curl` and `grep`. Maybe throw GNU parallel into the mix to speed things up. You might be able to provide some level of qutebrowser integration by implementing it as a userscript (e.g. to open the pages it finds). -Ryan On Wed 03/20/19 05:14PM, Stephen Davies (sdavies) wrote: > > Thanks to you both for your replies. > > Hey, as long as we're talking about dreamy enhancement requests, here's one > that I'm sure would be very hard to implement, but which I think would be a > killer feature. I'd love a way to search for text within "all pages that I've > bookmarked." (So not just the title of the pages, but their text.) > > Don't know if it'd be easier to snapshot and store the text of every page > as it's bookmarked, or to re-fetch the pages afresh whenever the user does the > aforementioned kind of search. There are pros and cons to each, but either one > would be a godsend. > > - Stephen > > Florian Bruhin wrote: > > Hey, > > > > On Wed, Mar 20, 2019 at 12:16:14PM -0400, Ryan Roden-Corrent wrote: > > > Bookmarks appear in the same order they appear in your bookmarks file. > > > New bookmarks are appended to the end, so they will actually appear > > > last. You can order the file however you like to change the order in the > > > qutebrowser UI, but newly added bookmarks will always go to the end. > > > > > > For what its worth, I rarely notice the order as I tend to rely on > > > text-filtering rather than scrolling. > > > > That's true for the :open completion, but not for qute://bookmarks which > > Stephen was referring to - that page indeed sorts by title only: > > > > https://secure-web.cisco.com/1ea8RLb1TXmxzxV0AaAIcZKknrIOT8j5CsdSJ2mMo8IJMoTbElws85qMqhofkHwNb8QBRGKzkmwwW2362q8XnGxCY46Q7srYHgEpYdH7ZHnjAnNxbzXLlCt-DZk-BDZrOw8XYFWvS2PIM2bXzrJlhP-VHLBm2BUii_mPtOzG0Rp-jwWLf9No57GR_23NfFX0aBz40PGqIMpPxoEJ8sztBYEENM3hrNnPk9yajlx_htJxFNIYYFg8-HEfh-C7Fj3I2vLgMEeTBJ-GYaMr8b_vmqnLKvoQ6dIdpOsi9nGgdi0lpIVid0_dgDFg7QNX9vr9e-DfAx3NnFbvRn82XynMAkw/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fblob%2Fv1.6.1%2Fqutebrowser%2Fbrowser%2Fqutescheme.py#L178-L181 > > > > Ideally the page itself would allow changing the sort order interactively. I > > guess many of the qute:// pages could need some love - I opened an issue with > > some ideas: https://secure-web.cisco.com/1GSehjjHGWDpdtTqWydfDlh5Z0iNtR7ag7QFR32QhISaY0lQHvdZe72-TzCj-yzH2sTCzKAQd0zS3pcB78gUz-NmDEVXXWMANj9VXtCwZ2j2PJ_u9JO_9SjtcYiiz31WCG5_vspYr8ZCpxk1sLmugvdrwSxnFjvvIPTGkn6mvIAs9VJRSfPOf4-hiInVYA10EvDoUfcfpj4z1dhfyfWR58I7TGmhKzmoTwd8J1t7zq0MrvftTSzzN7HvJZ6EcUiKoDeLpLlNAna63ts3GbNAbNFYIwGYi5qfaKD823Vxd_GE2Mc2qfz_SW-oKrCRc2G9837p3ln3vK9DQHyrz7SWEmg/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fissues%2F4662 > > > > Florian > > > > -- > > https://secure-web.cisco.com/1ZfjsCINYDU4PEppeN3EAeQtoK5r7Ibg4rZIQVlvAbq_A2l5u8duKgYpafWPXFYXwBAZFAmhlMgmoC_SA_4FDnorEKLZ43nFOtuHAe3asyq7lKtab5pJzgFoUtZasUYF1zUFM6MuNNWC7ngnWp5Fmux1gGK4DbeSWuqZ9o9CLWn4aApLIzA43KWNP9De9r8i1wvhsjY6KhYHdnv-LzSxPtkLgcIWdDcz2Fvjm-XdSCG1yqfsKPA69DScAMcqp0cxXOVaqspBUbw9l8ITp4e0If1vuBJqSTN-ZdwyvKtJ4-cq0Z6jLsdfYdEnAGGP3z7_qAEF7f1Jcu7x93HantXficg/https%3A%2F%2Fwww.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > > GPG: 916E B0C8 FD55 A072 | https://secure-web.cisco.com/1eugnSH_hyEpLN1D1d9OuimhbXTRzVHHIJyEcnvZIX9bT9B7YL9U8XN726-Teqt2EH-H-BjvW1xFpAo-MJ3vLdoFrkgrZ_denRy-ZOJwc73rYsO9le8d6NNf5uWXONMNcmNsbtn0H_e2j9A_ywfzBfxFi5PFB3__Jgni4Nqwrn2rjym7pfUAkrkSd_Tp72rDTt4Ybahn1WzX8Z_ajvNmf-s6SL2GfXSOjS34a0vyWaIt3J-A-WmDH-C_3dWfEwNZub3vp61rRPgL1DlPooCfwpVbRfDB9FieTBOvDxAaGj7bh7rFwsrvSXL-G0qlSolR60XymaTzaBBtusPUOe5cNoA/https%3A%2F%2Fthe-compiler.org%2Fpubkey.asc > > I love long mails! | https://secure-web.cisco.com/1JGNGBdKBO0dpCvng_NOODtQ5LuFmCDX0AquTeDQlFLdHRnFrM02y8oV24zADifxcITzujRtzdUzQIta3q4NYDB6qSP8dnPL646cxR5C2bgTQURCgyaWWuCYoCSfp5rIUxE5xm-jGykYzJRPp9eRIXtaQ6GKDbpR0MGBGkVma34pXQPd569eSfg2Np-onjubD2zlpmNDZGUk4M5OHkzfDeFUe0u_MoJMpEhxOsVsvvnRbP_lB6o9exAUWrWv8NCkDRve5l-55IDP4Ma18S7Tg5PeybPX7CAcl3vbi2jl2HUsZEZ44BZNspJOg712g0aoOagR-au96Yr8keHXUOtNxfw/https%3A%2F%2Femail.is-not-s.ms%2F > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ryan at rcorre.net Wed Mar 20 20:51:02 2019 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Wed, 20 Mar 2019 15:51:02 -0400 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320171417.GD3735@umw.edu> References: <20190320145755.GA17942@umw.edu> <20190320161614.GC753@midova.localdomain> <20190320163538.lavztct27obns4fq@hooch.localdomain> <20190320171417.GD3735@umw.edu> Message-ID: <20190320195102.GH753@midova.localdomain> This is actually an interesting question so I couldn't resist throwing together a quick script :) ``` #!/bin/sh search() { local token=$1 local url=$2 if curl -s "$url" | grep "$token" >/dev/null ; then echo "hit $url" fi } export -f search cut -d' ' -f1 ~/.config/qutebrowser/bookmarks/urls | parallel search "$1" {} ``` Its pretty naive and has plenty of room for improvement, but it seems to work for a few simple tests I threw at it. -Ryan On Wed 03/20/19 05:14PM, Stephen Davies (sdavies) wrote: > > Thanks to you both for your replies. > > Hey, as long as we're talking about dreamy enhancement requests, here's one > that I'm sure would be very hard to implement, but which I think would be a > killer feature. I'd love a way to search for text within "all pages that I've > bookmarked." (So not just the title of the pages, but their text.) > > Don't know if it'd be easier to snapshot and store the text of every page > as it's bookmarked, or to re-fetch the pages afresh whenever the user does the > aforementioned kind of search. There are pros and cons to each, but either one > would be a godsend. > > - Stephen > > Florian Bruhin wrote: > > Hey, > > > > On Wed, Mar 20, 2019 at 12:16:14PM -0400, Ryan Roden-Corrent wrote: > > > Bookmarks appear in the same order they appear in your bookmarks file. > > > New bookmarks are appended to the end, so they will actually appear > > > last. You can order the file however you like to change the order in the > > > qutebrowser UI, but newly added bookmarks will always go to the end. > > > > > > For what its worth, I rarely notice the order as I tend to rely on > > > text-filtering rather than scrolling. > > > > That's true for the :open completion, but not for qute://bookmarks which > > Stephen was referring to - that page indeed sorts by title only: > > > > https://secure-web.cisco.com/1ea8RLb1TXmxzxV0AaAIcZKknrIOT8j5CsdSJ2mMo8IJMoTbElws85qMqhofkHwNb8QBRGKzkmwwW2362q8XnGxCY46Q7srYHgEpYdH7ZHnjAnNxbzXLlCt-DZk-BDZrOw8XYFWvS2PIM2bXzrJlhP-VHLBm2BUii_mPtOzG0Rp-jwWLf9No57GR_23NfFX0aBz40PGqIMpPxoEJ8sztBYEENM3hrNnPk9yajlx_htJxFNIYYFg8-HEfh-C7Fj3I2vLgMEeTBJ-GYaMr8b_vmqnLKvoQ6dIdpOsi9nGgdi0lpIVid0_dgDFg7QNX9vr9e-DfAx3NnFbvRn82XynMAkw/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fblob%2Fv1.6.1%2Fqutebrowser%2Fbrowser%2Fqutescheme.py#L178-L181 > > > > Ideally the page itself would allow changing the sort order interactively. I > > guess many of the qute:// pages could need some love - I opened an issue with > > some ideas: https://secure-web.cisco.com/1GSehjjHGWDpdtTqWydfDlh5Z0iNtR7ag7QFR32QhISaY0lQHvdZe72-TzCj-yzH2sTCzKAQd0zS3pcB78gUz-NmDEVXXWMANj9VXtCwZ2j2PJ_u9JO_9SjtcYiiz31WCG5_vspYr8ZCpxk1sLmugvdrwSxnFjvvIPTGkn6mvIAs9VJRSfPOf4-hiInVYA10EvDoUfcfpj4z1dhfyfWR58I7TGmhKzmoTwd8J1t7zq0MrvftTSzzN7HvJZ6EcUiKoDeLpLlNAna63ts3GbNAbNFYIwGYi5qfaKD823Vxd_GE2Mc2qfz_SW-oKrCRc2G9837p3ln3vK9DQHyrz7SWEmg/https%3A%2F%2Fgithub.com%2Fqutebrowser%2Fqutebrowser%2Fissues%2F4662 > > > > Florian > > > > -- > > https://secure-web.cisco.com/1ZfjsCINYDU4PEppeN3EAeQtoK5r7Ibg4rZIQVlvAbq_A2l5u8duKgYpafWPXFYXwBAZFAmhlMgmoC_SA_4FDnorEKLZ43nFOtuHAe3asyq7lKtab5pJzgFoUtZasUYF1zUFM6MuNNWC7ngnWp5Fmux1gGK4DbeSWuqZ9o9CLWn4aApLIzA43KWNP9De9r8i1wvhsjY6KhYHdnv-LzSxPtkLgcIWdDcz2Fvjm-XdSCG1yqfsKPA69DScAMcqp0cxXOVaqspBUbw9l8ITp4e0If1vuBJqSTN-ZdwyvKtJ4-cq0Z6jLsdfYdEnAGGP3z7_qAEF7f1Jcu7x93HantXficg/https%3A%2F%2Fwww.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > > GPG: 916E B0C8 FD55 A072 | https://secure-web.cisco.com/1eugnSH_hyEpLN1D1d9OuimhbXTRzVHHIJyEcnvZIX9bT9B7YL9U8XN726-Teqt2EH-H-BjvW1xFpAo-MJ3vLdoFrkgrZ_denRy-ZOJwc73rYsO9le8d6NNf5uWXONMNcmNsbtn0H_e2j9A_ywfzBfxFi5PFB3__Jgni4Nqwrn2rjym7pfUAkrkSd_Tp72rDTt4Ybahn1WzX8Z_ajvNmf-s6SL2GfXSOjS34a0vyWaIt3J-A-WmDH-C_3dWfEwNZub3vp61rRPgL1DlPooCfwpVbRfDB9FieTBOvDxAaGj7bh7rFwsrvSXL-G0qlSolR60XymaTzaBBtusPUOe5cNoA/https%3A%2F%2Fthe-compiler.org%2Fpubkey.asc > > I love long mails! | https://secure-web.cisco.com/1JGNGBdKBO0dpCvng_NOODtQ5LuFmCDX0AquTeDQlFLdHRnFrM02y8oV24zADifxcITzujRtzdUzQIta3q4NYDB6qSP8dnPL646cxR5C2bgTQURCgyaWWuCYoCSfp5rIUxE5xm-jGykYzJRPp9eRIXtaQ6GKDbpR0MGBGkVma34pXQPd569eSfg2Np-onjubD2zlpmNDZGUk4M5OHkzfDeFUe0u_MoJMpEhxOsVsvvnRbP_lB6o9exAUWrWv8NCkDRve5l-55IDP4Ma18S7Tg5PeybPX7CAcl3vbi2jl2HUsZEZ44BZNspJOg712g0aoOagR-au96Yr8keHXUOtNxfw/https%3A%2F%2Femail.is-not-s.ms%2F > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From me at the-compiler.org Wed Mar 20 22:47:44 2019 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 20 Mar 2019 22:47:44 +0100 Subject: [qutebrowser] sorting bookmarks by recency In-Reply-To: <20190320171417.GD3735@umw.edu> References: <20190320145755.GA17942@umw.edu> <20190320161614.GC753@midova.localdomain> <20190320163538.lavztct27obns4fq@hooch.localdomain> <20190320171417.GD3735@umw.edu> Message-ID: <20190320214744.xzwazlreai7zatnh@hooch.localdomain> On Wed, Mar 20, 2019 at 05:14:17PM +0000, Stephen Davies (sdavies) wrote: > > Thanks to you both for your replies. > > Hey, as long as we're talking about dreamy enhancement requests, here's one > that I'm sure would be very hard to implement, but which I think would be a > killer feature. I'd love a way to search for text within "all pages that I've > bookmarked." (So not just the title of the pages, but their text.) > > Don't know if it'd be easier to snapshot and store the text of every page > as it's bookmarked, or to re-fetch the pages afresh whenever the user does the > aforementioned kind of search. There are pros and cons to each, but either one > would be a godsend. I agree this probably isn't something qutebrowser should solve by itself. FWIW I use Wallabag[1] as a "read it later" list - it does archive contents, which I'm mainly glad for because it ensures I can read things years later. It also allows full-text search through archived/"bookmarked" pages though! See https://wallabag.org/ Now what certainly would be nice is if you could integrate something like that with qutebrowser bookmarks. I added a point to the extension ideas here: https://github.com/qutebrowser/qutebrowser/issues/30 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 surround at gmail.com Fri Mar 22 17:27:01 2019 From: surround at gmail.com (David McSweeney) Date: Fri, 22 Mar 2019 16:27:01 +0000 Subject: [qutebrowser] RequestBin Message-ID: Hi, Hope your week is going good. I came across your page on contributing to qutebrowser today (this one ) and noticed you recommend RequestBin under useful websites. Not sure if you're aware, but the original hosted version of RequestBin (at requestb.in) was taken down last year. There's a new hosted version, with some additional features (including enhanced privacy) at https://requestbin.com If you had a couple of minutes spare to update the link, I would really appreciate it :) Have a great day! Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Fri Mar 22 22:19:59 2019 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 22 Mar 2019 22:19:59 +0100 Subject: [qutebrowser] RequestBin In-Reply-To: References: Message-ID: <20190322211959.ox2gxjiisxp6sfst@hooch.localdomain> Hey David, On Fri, Mar 22, 2019 at 04:27:01PM +0000, David McSweeney wrote: > If you had a couple of minutes spare to update the link, I would really > appreciate it :) Updated, thanks for the heads up! https://github.com/qutebrowser/qutebrowser/commit/58c6dd1f961682b79fc44fb7aee09353f9c0fe0b > Have a great day! You too! :) 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 tgy at inria.fr Thu Mar 28 10:27:25 2019 From: tgy at inria.fr (Valentin Iovene) Date: Thu, 28 Mar 2019 10:27:25 +0100 Subject: [qutebrowser] Can't locate dictcli.py on macOS Message-ID: <20190328092725.qhbffilw4iuweuqj@valoup> Hi, I need to install a new dictionary for spell checking in qutebrowser but I am having a hard time locating dictcli.py on macOS. I installed qutebrowser using `brew cask install qutebrowser`. I've tried to `locate dictcli.py` with no result, also looked in folders where I expected the script to be. On Arch Linux the file is at /usr/share/qutebrowser/scripts/dictcli.py It would be nice to have a way of installing new dictionaries from within qutebrowser, rather than having to find a script and run it. This would improve the already great user experience :-) Thanks, -- Valentin From me at the-compiler.org Thu Mar 28 11:25:04 2019 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 28 Mar 2019 11:25:04 +0100 Subject: [qutebrowser] Can't locate dictcli.py on macOS In-Reply-To: <20190328092725.qhbffilw4iuweuqj@valoup> References: <20190328092725.qhbffilw4iuweuqj@valoup> Message-ID: <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> On Thu, Mar 28, 2019 at 10:27:25AM +0100, Valentin Iovene wrote: > I need to install a new dictionary for spell checking in qutebrowser > but I am having a hard time locating dictcli.py on macOS. > > I installed qutebrowser using `brew cask install qutebrowser`. > > I've tried to `locate dictcli.py` with no result, also looked in > folders where I expected the script to be. I don't think it's possible to run it currently, as you can't launch qutebrowser's Python interpreter shipped with qutebrowser. See https://github.com/qutebrowser/qutebrowser/issues/3321 > It would be nice to have a way of installing new dictionaries from > within qutebrowser, rather than having to find a script and run it. > This would improve the already great user experience :-) I agree! The reason for the script was that it needs root to install dicitonaries on older Qt versions (< 5.10) and you wouldn't want to run qutebrowser as root. See https://github.com/qutebrowser/qutebrowser/issues/4003 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 javierayres at gmail.com Thu Mar 28 12:19:26 2019 From: javierayres at gmail.com (Javier Ayres) Date: Thu, 28 Mar 2019 08:19:26 -0300 Subject: [qutebrowser] Can't locate dictcli.py on macOS In-Reply-To: <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> References: <20190328092725.qhbffilw4iuweuqj@valoup> <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> Message-ID: I installed qutebrowser with pip for the sole purpose of downloading dictionaries. The pip version wouldn't work for me so I'm using the dmg installer, but anyway I installed it via pip, downloaded dictcli.py from GitHub (now that I think it's possible that it already comes with the version installed via pip...), ran it, and then deleted it and uninstalled qutebrowser from pip. Far from simple but it works. On Thu, Mar 28, 2019, 07:25 Florian Bruhin wrote: > On Thu, Mar 28, 2019 at 10:27:25AM +0100, Valentin Iovene wrote: > > I need to install a new dictionary for spell checking in qutebrowser > > but I am having a hard time locating dictcli.py on macOS. > > > > I installed qutebrowser using `brew cask install qutebrowser`. > > > > I've tried to `locate dictcli.py` with no result, also looked in > > folders where I expected the script to be. > > I don't think it's possible to run it currently, as you can't launch > qutebrowser's Python interpreter shipped with qutebrowser. > > See https://github.com/qutebrowser/qutebrowser/issues/3321 > > > It would be nice to have a way of installing new dictionaries from > > within qutebrowser, rather than having to find a script and run it. > > This would improve the already great user experience :-) > > I agree! The reason for the script was that it needs root to install > dicitonaries on older Qt versions (< 5.10) and you wouldn't want to run > qutebrowser as root. > > See https://github.com/qutebrowser/qutebrowser/issues/4003 > > 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 -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Mar 28 13:17:37 2019 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 28 Mar 2019 13:17:37 +0100 Subject: [qutebrowser] Can't locate dictcli.py on macOS In-Reply-To: References: <20190328092725.qhbffilw4iuweuqj@valoup> <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> Message-ID: <20190328121737.gpj357mgfrhcezfn@hooch.localdomain> On Thu, Mar 28, 2019 at 08:19:26AM -0300, Javier Ayres wrote: > I installed qutebrowser with pip for the sole purpose of downloading > dictionaries. The pip version wouldn't work for me so I'm using the dmg > installer, but anyway I installed it via pip, downloaded dictcli.py from > GitHub (now that I think it's possible that it already comes with the > version installed via pip...), ran it, and then deleted it and uninstalled > qutebrowser from pip. > > Far from simple but it works. Oh, right - I'd have expected that this doesn't work because of the different paths caused by the different Qt/Python versions. But it does with Qt >= 5.10 as they're saved in qutebrowser's data directory which stays the same. 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 tgy at inria.fr Thu Mar 28 14:38:32 2019 From: tgy at inria.fr (Valentin Iovene) Date: Thu, 28 Mar 2019 14:38:32 +0100 Subject: [qutebrowser] Can't locate dictcli.py on macOS In-Reply-To: <20190328121737.gpj357mgfrhcezfn@hooch.localdomain> References: <20190328092725.qhbffilw4iuweuqj@valoup> <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> <20190328121737.gpj357mgfrhcezfn@hooch.localdomain> Message-ID: <20190328133832.cbd43fz5qis2ykin@valoup> Thank you guys for your answers. I ended up cloning the qutebrowser repo from GitHub and running the following from within the repo python3 scripts/dictcli.py install it-IT and it worked out of the box. Note that running this did not ask for any root access. One solution might be to add an executable script in /usr/local/bin/qutebrowser-dictcli that allows people to at least simply install new dicts from the terminal? -- Valentin From me at the-compiler.org Thu Mar 28 15:55:56 2019 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 28 Mar 2019 15:55:56 +0100 Subject: [qutebrowser] Can't locate dictcli.py on macOS In-Reply-To: <20190328133832.cbd43fz5qis2ykin@valoup> References: <20190328092725.qhbffilw4iuweuqj@valoup> <20190328102504.hlzi2l7hbaszlyqw@hooch.localdomain> <20190328121737.gpj357mgfrhcezfn@hooch.localdomain> <20190328133832.cbd43fz5qis2ykin@valoup> Message-ID: <20190328145556.46wxdvellyb4esll@hooch.localdomain> On Thu, Mar 28, 2019 at 02:38:32PM +0100, Valentin Iovene wrote: > Note that running this did not ask for any root access. It only needs that for Qt < 5.10. > One solution might be to add an executable script in > > /usr/local/bin/qutebrowser-dictcli > > that allows people to at least simply install new dicts from the > terminal? An .app can't add a script to /usr/local/bin, and there isn't anything like an installer for qutebrowser (it's just a .dmg with an .app you drag to /Applications, like many macOS apps). 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 davidnebauer at hotkey.net.au Sat Mar 30 11:29:46 2019 From: davidnebauer at hotkey.net.au (David Nebauer) Date: Sat, 30 Mar 2019 10:29:46 -0000 Subject: [qutebrowser] Per domain open url in another browser In-Reply-To: <20190216052415.dgwh45ixtkfasghc@phi> References: <1550272745.wg4t532dpi.astroid@hezmana.none> <20190216052415.dgwh45ixtkfasghc@phi> Message-ID: <1551357755.hcjg2fwpmx.astroid@hezmana.none> Just realised I didn't copy my previous reply to Timoth?e to the list: qutebrowser installed from debian package 'qutebrowser' 1.5.2-1: $ qutebrowser -V qutebrowser v1.5.2 Git commit: Backend: QtWebEngine (Chromium 65.0.3325.230) CPython: 3.7.2+ Qt: 5.11.3 PyQt: 5.11.3 sip: 4.19.13 colorama: 0.3.7 pypeg2: 2.15 jinja2: 2.10 pygments: 2.3.1 yaml: 3.13 cssutils: no attr: 18.2.0 PyQt5.QtWebEngineWidgets: yes PyQt5.QtWebKitWidgets: yes pdf.js: 1.5.188 (/usr/share/javascript/pdf/build/pdf.js) sqlite: 3.26.0 QtNetwork SSL: OpenSSL 1.1.1a 20 Nov 2018 Style: QFusionStyle Platform: Linux-4.19.0-1-amd64-x86_64-with-debian-buster-sid, 64bit Linux distribution: Debian GNU/Linux buster/sid (debian) Frozen: False Imported from /usr/lib/python3/dist-packages/qutebrowser Using Python from /usr/bin/python3 Qt library executable path: /usr/lib/x86_64-linux-gnu/qt5/libexec, data path: /usr/share/qt5 Paths: cache: /home/david/.cache/qutebrowser config: /home/david/.config/qutebrowser data: /home/david/.local/share/qutebrowser runtime: /run/user/1000/qutebrowser system data: /usr/share/qutebrowser Excerpts from Timoth?e Floure's message of February 16, 2019 2:54 pm: > Hello, > >> On my system links from drive.google.com open in qutebrowser as blank >> pages. > > Can you share details on your system (`qutebrowser -V`)? Google Drive works > here on Fedora, there must be something wrong (or outdated) with your system. > > -- > Timoth?e > > On Sat, Feb 16, 2019 at 08:53:20AM +0930, David Nebauer wrote: >> I'm sure this must have been raised before, but I can't find it in >> github issues or by web googling. >> >> On my system links from drive.google.com open in qutebrowser as blank >> pages. I've set up a key combination to manually spawn those links in >> another browser. Can I, instead, set up qutebrowser to automatically >> spawn links from a specified domain in another browser? >> >> David >