From jocelyn.turcotte at digia.com Mon Jan 5 19:18:01 2015 From: jocelyn.turcotte at digia.com (Jocelyn Turcotte) Date: Mon, 5 Jan 2015 19:18:01 +0100 Subject: [Qtwebengine] Hopeful of a timeline? In-Reply-To: References: Message-ID: <20150105181801.GA1014@poutine.it.local> Hello David, You can find some of that information at: http://doc.qt.io/qt-5/qtwebenginewidgets-qtwebkitportingguide.html Some of the features like private browsing should already be available in Qt 5.5. We currently have an internal development board at https://trello.com/b/5G9c1rkb/qtwebengine that you can follow and you can use the Qt bug tracker to vote and report issues or missing important features. I have to note that QtWebEngine isn't a 1-to-1 replacement of QtWebKit, principally because some very advanced features can't be set in stone through a public API without risking huge future maintenance efforts as Chromium evolves under our feet. It is quite a dragon to ride. The public API aims at solving the general use case of embedding web contents in Qt applications, but if you are developping a more powerful application I encourage you to look at the code and dig further to get access to functionalities that you need, keeping in mind that the further you dig, the more likely you'll have to update your code between QtWebEngine updates. Cheers, Jocelyn On Mon, Dec 29, 2014 at 05:28:19PM -0800, David Cortesi wrote: > I was glad when Qt5.4 was released because I was eager to use QWebEngine. > However when I began to port my app (a simple special-purpose browser) I > was surprised to find some QWebKit features not (yet?) supported. Reading > the archives of this list, it appears I was not the only one surprised -- > but surprise would be natural, given statements such as this from the digia > blog (http://blog.qt.digia.com/blog/2014/12/10/qt-5-4-released/) > > HTML5 and Web technologies have become more and more important over the > > last years, and we have spent the last year developing a completely renewed > > Web offering for Qt. The Qt WebEngine > > module is the result of a > > long-term R&D project where we adopted the Chromium Web engine for use > > within Qt. With Qt 5.4, it is fully supported on the most used desktop and > > embedded platforms. Qt WebEngine provides you with an easy-to-use API to > > embed Web content in both Qt Widgets and Qt Quick based applications. > > > > Nothing in that announcement suggests that WebEngine is only partially > finished. Indeed, "completely renewed offering" and "fully supported" might > make a person think it is ready to replace WebKit. > > Well, that would be a problem of communication from dev. to marketing, > perhaps -- anyway it's water under the bridge! > > What I would hope to see happen now is to assemble a list of WebKit > features that are NOT available in WebEngine 5.4, with some indication of > whether each feature is (a) not planned (b) planned but with a different > API (c) planned for 5.5, (d) planned for someday, etc. > > Here in no particular order are things that I could not port to WebEngine > in my simple app: > > Settings: PluginsEnabled(bool) > > Settings: JavaEnabled(bool) -- I suspect in Chromium this is subsumed under > "plugins" > > Settings: PrivateBrowsingEnabled(bool) -- Chrome browser definitely > supports it > > QWebFrame::hitTestContent(QPosition) -- necessary for a custom context menu > to adapt to "what's clicked" > > QWebPage.setContentEditable(bool) -- looks as if currently WebEngine pages > are not editable, could they ever be? > > QWebPage.setLinkDelegationPolicy(policy) and the associated > linkClicked(URL) signal. > > What else? And is there a timeline, or at least priority list, for these > things? > > Thanks for your attention, > > Dave Cortesi > _______________________________________________ > QtWebEngine mailing list > QtWebEngine at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qtwebengine From jocelyn.turcotte at digia.com Mon Jan 5 19:35:55 2015 From: jocelyn.turcotte at digia.com (Jocelyn Turcotte) Date: Mon, 5 Jan 2015 19:35:55 +0100 Subject: [Qtwebengine] Build QtWebEngine on RaspBerry Pi In-Reply-To: References: <20141118065602.GB32338@tonks> <20141119124138.GK32338@tonks> Message-ID: <20150105183555.GB1014@poutine.it.local> Hello, QtWebEngine is only supported (as in "we'll provide fixes or workarounds for customers on supported devices") with Qt for Device Creation but you can also use it through the LGPLv3 licence that comes with the open source version, as long as the licence fit your needs. That said, QtWebEngine is quite heavy and you might get variable milleage on a limited device like the RPi. The QtWebKit 3.0 QML module might get you further in this situation, sadly with compromises. Cheers, Jocelyn On Mon, Dec 22, 2014 at 03:24:18PM +0100, LongChair69 . wrote: > I have been trying to figure out how to get a decent performance on RPi, > but i'm coming i think to a dead end until i overlooked something. > > my current app requires to use C++ and we would like to avoid any qml stuff > as it's causing some issue with embedding some external components outside > qt world. > > As far as i have understood (correct me if i'm wrong) there are 3 > possibilities : > > - Use QWebView in c++ : this leads to very poor performance on the rpi as > it seems it will not use any hw accelerated backend. > - Use QWebView with qml : this gives good performance, but causes issues to > the other components we have to glue with. > - Use QWebEngine : that was looking like a great thing, but the restriction > of having the need for a QT embedded licence (where it was not the case up > to now) looks like a very bad turn for homebrew developpers. Most Raspberry > Pi applications are free and hombrew devs cannot afford Qt embedded version > for community development. > > So did i miss something in my experimentations or am i coming to a dead end > ? > > How can i achieve both performance, keep c++ without having to get qt > embedded ? > > Any thoughts / comments are welcome ! :) > > 2014-11-19 13:41 GMT+01:00 Florian Bruhin : > > > * LongChair69 . [2014-11-19 13:31:08 +0100]: > > > Ok i gave it a shot with QtGraphicsWebview and the simple sample below : > > > > > > [...] > > > > > > the url used is a small site to test css transforms with / without > > > acceleration. > > > given the speed i'm hitting on this sample, it doesn't looks like it is > > > using any HW acceleration. > > > > > > Is there anything that i did wrong in the sample above, or any suggestion > > > that would explain it's not hitting hw ? > > > > I've not tried QGraphicsWebView myself yet so I'm only guessing, but > > maybe you need to call setViewport on the QGraphicsView with a > > QGLWidget? > > > > From http://qt-project.org/doc/qt-5/qgraphicsview.html : > > > > By default, QGraphicsView provides a regular QWidget for the > > viewport widget. You can access this widget by calling viewport(), > > or you can replace it by calling setViewport(). To render using > > OpenGL, simply call setViewport(new QGLWidget). QGraphicsView > > takes ownership of the viewport widget. > > > > The blog post I linked before ([1]) alsop suggests this: > > > > - Setting the QGraphicsView’s viewportUpdateMode to > > BoundingRectViewportUpdate > > > > Florian > > > > [1] > > http://blog.qt.digia.com/blog/2010/05/17/qtwebkit-now-accelerates-css-animations-3d-transforms/ > > > > -- > > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > > GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc > > I love long mails! | http://email.is-not-s.ms/ > > > > _______________________________________________ > > QtWebEngine mailing list > > QtWebEngine at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/qtwebengine > > > > > _______________________________________________ > QtWebEngine mailing list > QtWebEngine at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qtwebengine From flying-sheep at web.de Tue Jan 6 00:40:56 2015 From: flying-sheep at web.de (Philipp A.) Date: Tue, 6 Jan 2015 00:40:56 +0100 Subject: [Qtwebengine] Hopeful of a timeline? In-Reply-To: <20150105181801.GA1014@poutine.it.local> References: <20150105181801.GA1014@poutine.it.local> Message-ID: Hi! 2015-01-05 19:18 GMT+01:00 Jocelyn Turcotte : > I have to note that QtWebEngine isn't a 1-to-1 replacement of QtWebKit, > principally because some very advanced features can't be set in stone > through a public API without risking huge future maintenance efforts as > Chromium evolves under our feet. It is quite a dragon to ride. > I’m sorry to say that, but that’s awful to hear. I expected QWebEngine to be *more* powerful than QWebkit. Things like cookie management and complete control over requests, as well as access to the devtools are essential features for every more complex application. and that’s just the obvious puzzlers that i immediately stumbled upon. The public API aims at solving the general use case of embedding web > contents in Qt applications, This is already solved by simple stuff like the QML WebView. > but if you are developping a more powerful > application I encourage you to look at the code and dig further to get > access to functionalities that you need, keeping in mind that the > further you dig, the more likely you'll have to update your code between > QtWebEngine updates. > So you’re saying that we need to compile our own version of QWebEngine with custom patches? I think many people expected it to be QWebkit with API cruft removed and a new backend. but now we are in the sad position to have a deprecated QWebkit that can do what we want (except modern HTML5 because it’s frozen) and a castrated QWebEngine that can’t and possibly won’t ever be able to do necessary things (if i understood you correctly) again: i don’t want to descredit the hard work that went into executing the switch, but i question the research that went into the decision to abandon something with adequate capabilities for something with less. best, philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocelyn.turcotte at digia.com Tue Jan 6 12:19:45 2015 From: jocelyn.turcotte at digia.com (Jocelyn Turcotte) Date: Tue, 6 Jan 2015 12:19:45 +0100 Subject: [Qtwebengine] Hopeful of a timeline? In-Reply-To: References: <20150105181801.GA1014@poutine.it.local> Message-ID: <20150106111945.GA1674@poutine.it.local> Hello Philipp, On Tue, Jan 06, 2015 at 12:40:56AM +0100, Philipp A. wrote: > Hi! > > 2015-01-05 19:18 GMT+01:00 Jocelyn Turcotte : > > > I have to note that QtWebEngine isn't a 1-to-1 replacement of QtWebKit, > > principally because some very advanced features can't be set in stone > > through a public API without risking huge future maintenance efforts as > > Chromium evolves under our feet. It is quite a dragon to ride. > > > > I’m sorry to say that, but that’s awful to hear. I expected QWebEngine to > be *more* powerful than QWebkit. > > Things like cookie management and complete control over requests, as well > as access to the devtools are essential features for every more complex > application. and that’s just the obvious puzzlers that i immediately > stumbled upon. It will be more powerful on the web API completeness and reliability's point of view, but some features like complete control over requests might not be possible (and locked through a public API and binary compatibility promise) unless the Chromium team already ship this feature to let us believe that we can maintain only an API wrapper downstream. We believe that we can't ship such downstream features forever without increasing our bug count significantly over time. Basic cookie management and devtools are however perfectly doable and are on the schedule for 5.5 already. > The public API aims at solving the general use case of embedding web > > contents in Qt applications, > > > This is already solved by simple stuff like the QML WebView. For simple web contents yes, but more advanced content like WebGL and multimedia soon gets problematic. > > but if you are developping a more powerful > > application I encourage you to look at the code and dig further to get > > access to functionalities that you need, keeping in mind that the > > further you dig, the more likely you'll have to update your code between > > QtWebEngine updates. > > > > So you’re saying that we need to compile our own version of QWebEngine with > custom patches? > > I think many people expected it to be QWebkit with API cruft removed and a > new backend. but now we are in the sad position to have a deprecated > QWebkit that can do what we want (except modern HTML5 because it’s frozen) > and a castrated QWebEngine that can’t and possibly won’t ever be able to do > necessary things (if i understood you correctly) > > again: i don’t want to descredit the hard work that went into executing the > switch, but i question the research that went into the decision to abandon > something with adequate capabilities for something with less. What you consider cruft is important for other people, and vice versa. We have to find a good compromise between what we can maintain using the money paid for Qt licences + external contributions and finding a set of features that fits the needs of most Qt applications interacting with web contents. Some features can be made public with reasonable maintenance, some small features can be implemented and maintain downstream and exposed through internal interfaces to keep the flexibility of updating the design as Chromium itself changes, but bigger features that matter only to a handful of applications should be kept in a branch or custom patches. QtWebKit was lucky to be maintained upstream with the promise of Apple and Google not to break our tests (to their expense but for our benefit) and with a lot of development effort from Nokia, but still it had difficulty shipping more platform integrated web features like multimedia. QtWebEngine tries to stay conservative to keep as much of Chromium's reliability even though it is developped downstream, in a similar way to how your application is developped downstream from Qt but with the advantage of a public API. Cheers, Jocelyn From flying-sheep at web.de Tue Jan 6 18:03:22 2015 From: flying-sheep at web.de (Philipp A.) Date: Tue, 6 Jan 2015 18:03:22 +0100 Subject: [Qtwebengine] Hopeful of a timeline? In-Reply-To: <20150106111945.GA1674@poutine.it.local> References: <20150105181801.GA1014@poutine.it.local> <20150106111945.GA1674@poutine.it.local> Message-ID: 2015-01-06 12:19 GMT+01:00 Jocelyn Turcotte : > It will be more powerful on the web API completeness and reliability's > point of view, but some features like complete control over requests might > not be possible (and locked through a public API and binary compatibility > promise) unless the Chromium team already ship this feature to let us > believe that we can maintain only an API wrapper downstream. We believe > that we can't ship such downstream features forever without increasing our > bug count significantly over time. Basic cookie management and devtools > are however perfectly doable and are on the schedule for 5.5 already. > yeah, thanks for the trello link! it’s strange though: https://codereview.qt-project.org/#/c/97486/ this is listed under “done in 5.4”, but acceptNavigationRequest only exists in the dev branch… For simple web contents yes, but more advanced content like WebGL and > multimedia soon gets problematic. > OK, but that’s even more reason to want a component that can all that *and* everything QtWebkit was able to do :) What you consider cruft is important for other people, and vice versa. You misunderstood me: i meant that, like every rewrite, QtWebEngine surely had some architecture cleanups born from lesson learned while developing QtWebkit. Some features can be made public with reasonable maintenance, some small > features can be implemented and maintain downstream and exposed through > internal interfaces to keep the flexibility of updating the design as > Chromium itself changes, but bigger features that matter only to a handful > of applications should be kept in a branch or custom patches. > What are you getting at? Seems that many important things are in the “doing” or “todo” categories in trello. > QtWebKit was lucky to be maintained upstream with the promise of Apple and > Google not to break our tests (to their expense but for our benefit) and > with a lot of development effort from Nokia, but still it had difficulty > shipping more platform integrated web features like multimedia. > Ah, interesting. so why switch to chromium where this promise possibly (IDK, please tell me) doesn’t exist? Seems like giving up an advantage, but i’m sure you had your reasons! > QtWebEngine tries to stay conservative to keep as much of Chromium's > reliability even though it is developped downstream, in a similar way to > how your application is developped downstream from Qt but with the > advantage of a public API. > well, chromiums public API is relatively exensive, so i’m pretty sure one can implement many things on top of it. (if you mean https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/ ) Cheers, > Jocelyn > thanks for the explanations, philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From tangk at lemote.com Thu Jan 8 13:49:32 2015 From: tangk at lemote.com (tangk at lemote.com) Date: Thu, 8 Jan 2015 20:49:32 +0800 Subject: [Qtwebengine] how to load plugin such as flash plugin? Message-ID: <201501082049308849273@lemote.com> hi all : Now, I want to porting my project from qt5.3 to qt5.4. and I want to use qtwebengine instead of qtwebkit. but when I edit the code and found the qtwebenginesettings can not the attributes "PluginsEnabled", so I ignore it. but when I load the url, found that the "flash plugin" is not load. How can i resolve it? thanks very much. tangk at lemote.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Jan 8 13:54:04 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 8 Jan 2015 13:54:04 +0100 Subject: [Qtwebengine] how to load plugin such as flash plugin? In-Reply-To: <201501082049308849273@lemote.com> References: <201501082049308849273@lemote.com> Message-ID: <20150108125403.GS25530@tonks> Hi, * tangk at lemote.com [2015-01-08 20:49:32 +0800]: > Now, I want to porting my project from qt5.3 to qt5.4. and I want to > use qtwebengine instead of qtwebkit. but when I edit the code and > found the qtwebenginesettings can not the attributes > "PluginsEnabled", so I ignore it. but when I load the url, found > that the "flash plugin" is not load. QtWebEngine doesn't do plugins (yet?): https://trello.com/c/xH2kPw8T 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: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From tangk at lemote.com Thu Jan 8 14:45:17 2015 From: tangk at lemote.com (tangk at lemote.com) Date: Thu, 8 Jan 2015 21:45:17 +0800 Subject: [Qtwebengine] how to load plugin such as flash plugin? References: <201501082049308849273@lemote.com>, <20150108125403.GS25530@tonks> Message-ID: <201501082145161026016@lemote.com> ok, thanks very much. btw: how can I set the cache of the view? in old version, I can use the QNetworkAccessManager to setCacheDirectory, but Qt WebEngine does not interact with QNetworkAccessManager best regards tangk at lemote.com From: Florian Bruhin Date: 2015-01-08 20:54 To: qtwebengine Subject: Re: [Qtwebengine] how to load plugin such as flash plugin? Hi, * tangk at lemote.com [2015-01-08 20:49:32 +0800]: > Now, I want to porting my project from qt5.3 to qt5.4. and I want to > use qtwebengine instead of qtwebkit. but when I edit the code and > found the qtwebenginesettings can not the attributes > "PluginsEnabled", so I ignore it. but when I load the url, found > that the "flash plugin" is not load. QtWebEngine doesn't do plugins (yet?): https://trello.com/c/xH2kPw8T 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/ _______________________________________________ QtWebEngine mailing list QtWebEngine at qt-project.org http://lists.qt-project.org/mailman/listinfo/qtwebengine -------------- next part -------------- An HTML attachment was scrubbed... URL: From BCheng at intercalleurope.com Thu Jan 8 15:06:30 2015 From: BCheng at intercalleurope.com (Cheng, Bobber) Date: Thu, 8 Jan 2015 14:06:30 +0000 Subject: [Qtwebengine] how to load plugin such as flash plugin? In-Reply-To: <20150108125403.GS25530@tonks> References: <201501082049308849273@lemote.com> <20150108125403.GS25530@tonks> Message-ID: <0606501861F0A446AC23CAD47518E5B912EB25F619@lon01cexmbx01.us.intercall.com> Can anyone explain how to make pp flash player run on qtwebengine or qtwebengine neither support pp plugin nor npapi plugin? Regards, Bobber Sent with AquaMail for Android http://www.aqua-mail.com On 2015年1月8日 PM8:54:18 Florian Bruhin wrote: > Hi, > > * tangk at lemote.com [2015-01-08 20:49:32 +0800]: > > Now, I want to porting my project from qt5.3 to qt5.4. and I want to > > use qtwebengine instead of qtwebkit. but when I edit the code and > > found the qtwebenginesettings can not the attributes > > "PluginsEnabled", so I ignore it. but when I load the url, found > > that the "flash plugin" is not load. > > QtWebEngine doesn't do plugins (yet?): https://trello.com/c/xH2kPw8T > > 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/ From rmolla at adista.fr Thu Jan 8 15:32:23 2015 From: rmolla at adista.fr (Renaud MOLLA) Date: Thu, 8 Jan 2015 14:32:23 +0000 Subject: [Qtwebengine] Running Chrome Apps in QtWebEngine Message-ID: Hello, I'd like to know if it is possible to run chrome apps inside qtwebengine, and more specifically if screen capture/screencast apps would work. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Jan 8 16:15:53 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 8 Jan 2015 16:15:53 +0100 Subject: [Qtwebengine] how to load plugin such as flash plugin? In-Reply-To: <201501082145161026016@lemote.com> References: <201501082049308849273@lemote.com> <20150108125403.GS25530@tonks> <201501082145161026016@lemote.com> Message-ID: <20150108151553.GT25530@tonks> * tangk at lemote.com [2015-01-08 21:45:17 +0800]: > btw: how can I set the cache of the view? in old version, I can use > the QNetworkAccessManager to setCacheDirectory, but Qt WebEngine > does not interact with QNetworkAccessManager Based on what I see at [1] I believe it just caches to QStandardPaths::CacheLocation. This could be configured on Unix by setting $XDG_CACHE_HOME, but probably not on other systems... Flo [1] https://qt.gitorious.org/qt/qtwebengine/commit/f343e9d69a9aa8d64fe61725cf17c824f8f2d703 -- 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: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From davecortesi at gmail.com Fri Jan 16 21:55:00 2015 From: davecortesi at gmail.com (David Cortesi) Date: Fri, 16 Jan 2015 12:55:00 -0800 Subject: [Qtwebengine] KeyPressEvent not implemented? Message-ID: I converted a simple browser app to use QWebEngineView from QWebView. In the original QWebView widget I had an overriding keyPressEvent() handler which worked. Now that my widget is derived from QWebEngineView, the keyPressEvent handler is never entered. I have set self.focusPolicy(Qt::StrongFocus) and I can click in the web view, and when keys are pressed, no events are passed to the handler. Is this a known restriction of the new QWebEngineView? Certainly QWidget::keyPressEvent() does appear in the list of all members in the doc. Thanks, Dave Cortesi -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Fri Jan 16 22:05:12 2015 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 16 Jan 2015 22:05:12 +0100 Subject: [Qtwebengine] KeyPressEvent not implemented? In-Reply-To: References: Message-ID: <20150116210512.GN30488@tonks> * David Cortesi [2015-01-16 12:55:00 -0800]: > I converted a simple browser app to use QWebEngineView from QWebView. In > the original QWebView widget I had an overriding keyPressEvent() handler > which worked. Out of curiosity: What are you working on exactly? > Now that my widget is derived from QWebEngineView, the keyPressEvent > handler is never entered. I have set self.focusPolicy(Qt::StrongFocus) and > I can click in the web view, and when keys are pressed, no events are > passed to the handler. > > Is this a known restriction of the new QWebEngineView? Certainly > QWidget::keyPressEvent() does appear in the list of all members in the doc. I think this is the same limitation as in https://bugreports.qt.io/browse/QTBUG-43602 Mouse events are caught by a child QWidget of the QWebEngineView, and not by the QWebEngineView itself. This is a limitation of the current QtWebEngine design. There are also two workarounds mentioned there: A workaround could be to monitor QObject::childEvent of the QWebEngineView and install an event filter when a new child QWidget appear during page loads. I haven't tried this approach myself though, it might not be as reliable as needed for various reasons, and might break in future releases if the way we parent widgets internally changes. Another way would be to wrap the QWebEngineView (and its children) in a QWidget sandwich where a "glass" sibbling placed on top of the webview would catch any mouse event before it reaches the QWebEngineView's children under 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: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From davecortesi at gmail.com Sat Jan 17 18:27:49 2015 From: davecortesi at gmail.com (David Cortesi) Date: Sat, 17 Jan 2015 09:27:49 -0800 Subject: [Qtwebengine] KeyPressEvent not implemented? Message-ID: From: Florian Bruhin > > Out of curiosity: What are you working on exactly? > A simple reader for web comics: https://github.com/tallforasmurf/CoBro/blob/master/README.md I think this is the same limitation as in > https://bugreports.qt.io/browse/QTBUG-43602 > > Mouse events are caught by a child QWidget of the QWebEngineView, > and not by the QWebEngineView itself. This is a limitation of the > current QtWebEngine design. > I think you are correct. In my opinion this is an awful design choice, as it effectively eliminates not only mouse events as noted, but (it seems) keypress events. It would seem not impossible for this hidden "child widget" to pass events along to its parent. That might be tricky to implement, but it would keep the tricky-ness inside Qt instead of encouraging developers to proliferate their own obscure and fragile work-arounds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.rossi at gmail.com Mon Jan 19 11:40:03 2015 From: pierre.rossi at gmail.com (Pierre Rossi) Date: Mon, 19 Jan 2015 11:40:03 +0100 Subject: [Qtwebengine] Running Chrome Apps in QtWebEngine In-Reply-To: References: Message-ID: Hi Renaud, Unfortunately, we don't have support for any of Chrome's extensions' API in QtWebEngine at the moment. While we didn't rule out the possibility entirely, a number of features wouldn't even necessarily make sense in the context of QtWebEngine In the case of screen capture (which is not part of the WebRTC proposal atm), this used to be behind a chrome flag, for which we had a way to enable it (which would still prompt the end user for permission), but the chromium folks seem to have decided to move that functionality to their extension API to provide a nicer story for Chrome users. This would in fact be one of the good candidates, were we to introduce some extension API. This means we currently don't have an easy way to use Desktop capture in QtWebEngine. I'm happy to help out in any way I can if you're considering contributing in that area. Cheers, -- Pierre On Thu, Jan 8, 2015 at 3:32 PM, Renaud MOLLA wrote: > Hello, > > I'd like to know if it is possible to run chrome apps inside > qtwebengine, and more specifically if screen capture/screencast apps would > work. > > Regards. > > _______________________________________________ > QtWebEngine mailing list > QtWebEngine at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qtwebengine > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From okraits at arcor.de Fri Jan 23 08:23:40 2015 From: okraits at arcor.de (okraits at arcor.de) Date: Fri, 23 Jan 2015 08:23:40 +0100 (CET) Subject: [Qtwebengine] OpenGL issues when using QWebEngineView Message-ID: <284689192.33556.1421997820862.JavaMail.ngmail@webmail14.arcor-online.net> Hello everyone, i'm building a C++ application which uses QWebEngineView. It compiles without error. When i try to run it, i get the following error messages related to OpenGL: QOpenGLFramebufferObject: Framebuffer incomplete attachment. QOpenGLFramebufferObject: Framebuffer incomplete, missing draw buffer. QOpenGLFramebufferObject: Framebuffer incomplete, missing draw buffer. QOpenGLFramebufferObject: Framebuffer incomplete, missing draw buffer. QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment. QOpenGLShader: could not create shader QOpenGLShader: could not create shader QOpenGLShader: could not create shader The program crashed. I'm using Arch Linux, Qt 5.4.0 and an Intel 855GM Chipset with the i915 driver. How can i fix this? Thank you for your help in advance. Greetings, Oliver From jocelyn.turcotte at digia.com Thu Jan 29 18:43:25 2015 From: jocelyn.turcotte at digia.com (Jocelyn Turcotte) Date: Thu, 29 Jan 2015 18:43:25 +0100 Subject: [Qtwebengine] KeyPressEvent not implemented? In-Reply-To: References: Message-ID: <20150129174325.GD21169@poutine.it.local> Hello David, Sorry for the late answer, I was looking at the possible ways of dealing with the issue. On Sat, Jan 17, 2015 at 09:27:49AM -0800, David Cortesi wrote: > From: Florian Bruhin > > > > > Out of curiosity: What are you working on exactly? > > > > A simple reader for web comics: > > https://github.com/tallforasmurf/CoBro/blob/master/README.md > > I think this is the same limitation as in > > https://bugreports.qt.io/browse/QTBUG-43602 > > > > Mouse events are caught by a child QWidget of the QWebEngineView, > > and not by the QWebEngineView itself. This is a limitation of the > > current QtWebEngine design. > > > > I think you are correct. In my opinion this is an awful > design choice, as it effectively eliminates not only > mouse events as noted, but (it seems) keypress events. > > It would seem not impossible for this hidden "child widget" > to pass events along to its parent. That might be tricky > to implement, but it would keep the tricky-ness inside Qt > instead of encouraging developers to proliferate their > own obscure and fragile work-arounds. It can't pass events to its parent since Chromium has multiple underlying widgets for a single QWebEngineView, part of it because they need to be able to seamlessly switch from one to another when navigating between pages backed by different QtWebEngineProcesses. Sending those events to the common QWebEngineView first would mean that we'd have to demultiplex them afterward in a possible QWebEngineView::keyPressEvent implementation, which would surely bring a few bugs when dealing with edge cases. I don't know how you can do this in python, but for key events you have the option of using QAction, QShortcut or a general application event filter as described in http://doc.qt.io/qt-5/qcoreapplication.html#notify. If you only want the key events to be intercepted when the web view has the focus you currently can only do the event filter trick on the QWebEngineView's chidren as mentioned in QTBUG-43602. For the general case where you would want to give priority to the web page and get unhandled key events instead of intercepting them, I uploaded a fix at https://codereview.qt-project.org/104901 that should be released with 5.5.0. This will propagate unhandled events back to the parent, which we are currently never doing in 5.4. I hope this helps a bit. Cheers, Jocelyn From deblauwetom at gmail.com Fri Jan 30 16:20:12 2015 From: deblauwetom at gmail.com (Tom Deblauwe) Date: Fri, 30 Jan 2015 16:20:12 +0100 Subject: [Qtwebengine] webengine crash Message-ID: <54CBA12C.8010206@gmail.com> Hello, I am trying out QtWebEngine 5.4.0 and I'm having a crash when enabling javascript. I am crosscompiling for 32-bit on a 64-bit linux using buildroot. I get it to compile and run, but only when I disable javascript. Upon further investigation, I found it has something to do with some types of javascript. I tested some things and it seems I get the crash with "jquery" version 1.11.0, like for example that is used on "xkcd.org". When I use the latest "jquery" I don't get the crash, e.g. jquery 2.1.3. Anyway, in all cases, the last part of the stack trace is almost the same. It always ends with the "WriteToFlat" function. I have set a breakpoint and the function works, it is not crashing on the first try, but after a while it seems. Then I also checked that it was not some sort of javascript out of memory thing, so I wrote a little javascript that just creates a huge array, and that fails gratiously, it doesn't crash. So it seems it is really some kind of internal issue. I suspect it has something to do with regular expressions, or maybe the "String::Flatten" function is called often in regexp's. Anyways, on this line: src/3rdparty/chromium/v8/src/jsregexp.cc:169 There is a "pattern = String::Flatten(pattern);" call. So any clues in what direction I would have to search to find the problem? The problem is not reproducable when I use the regular desktop builds downloadable using the qt installer. On different sites I have differen backtraces, but all end with a call to "WriteToFlat". And when I disable javascript, every site renders okay, so there is not a problem with the rendering itself, everything is seen as intended. Any help would be greatly appreciated! Best regards, Tom Deblauwe gdb --args ./browser --log-level=0 --single-process (gdb) bt #0 v8::internal::String::WriteToFlat (src=0xdd094881, src at entry=0xdd0949a9, sink=sink at entry=0xdd094e8c "\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336)*)|.*)\\)|)\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336"..., f=119, f at entry=0, t=171) at ../../../src/3rdparty/chromium/v8/src/objects.cc:8823 #1 0xeeceae64 in v8::internal::String::WriteToFlat (src=0xdd0949ed, sink=0xdd094e15 "\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336)*)|.*)\\)|)\336\357\276\255\336\357\276\255\336\357\276\255\336\357\276\255\336\357"..., f=f at entry=0, t=171, t at entry=263) at ../../../src/3rdparty/chromium/v8/src/objects.cc:8864 #2 0xeecec384 in v8::internal::String::SlowFlatten (cons=cons at entry=..., pretenure=pretenure at entry=v8::internal::NOT_TENURED) at ../../../src/3rdparty/chromium/v8/src/objects.cc:1044 #3 0xee9f800a in v8::internal::String::Flatten (string=..., pretenure=v8::internal::NOT_TENURED) at ../../../src/3rdparty/chromium/v8/src/objects-inl.h:3180 #4 0xeec50fd8 in v8::internal::RegExpImpl::Compile (re=re at entry=..., pattern=pattern at entry=..., flag_str=...) at ../../../src/3rdparty/chromium/v8/src/jsregexp.cc:169 #5 0xeed7e513 in __RT_impl_Runtime_RegExpCompile (isolate=0xe79450d0, args=...) at ../../../src/3rdparty/chromium/v8/src/runtime.cc:2124 #6 v8::internal::Runtime_RegExpCompile (args_length=3, args_object=0xe16f2ee0, isolate=0xe79450d0) at ../../../src/3rdparty/chromium/v8/src/runtime.cc:2117 #7 0x20e0a076 in ?? () #8 0x20e594f2 in ?? () #9 0x20e3b0c4 in ?? () #10 0x20e1e85b in ?? () #11 0x20e1eb3b in ?? () #12 0x3750ad73 in ?? () #13 0x3750fe29 in ?? () #14 0x20e1e85b in ?? () #15 0x20e80a11 in ?? () #16 0x20e80b6b in ?? () #17 0x20e1edf5 in ?? () #18 0x20e1e0ea in ?? () #19 0xeeae7336 in v8::internal::Invoke (is_construct=is_construct at entry=false, function=function at entry=..., receiver=..., receiver at entry=..., argc=argc at entry=0, args=args at entry=0x0) at ../../../src/3rdparty/chromium/v8/src/execution.cc:94 #20 0xeeae9580 in v8::internal::Execution::Call (isolate=isolate at entry=0xe79450d0, callable=..., callable at entry=..., receiver=..., argc=argc at entry=0, argv=argv at entry=0x0, convert_receiver=convert_receiver at entry=false) at ../../../src/3rdparty/chromium/v8/src/execution.cc:149 #21 0xeea1ceba in v8::Script::Run (this=0xe796bd48) at ../../../src/3rdparty/chromium/v8/src/api.cc:1637 #22 0xf15b8aa8 in WebCore::V8ScriptRunner::runCompiledScript (script=..., context=0x5f404078, isolate=0xe79450d0) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/bindings/v8/V8ScriptRunner.cpp:105 #23 0xf1562e44 in WebCore::ScriptController::executeScriptAndReturnValue (this=0xe7970d88, context=..., source=..., corsStatus=WebCore::NotSharableCrossOrigin) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/bindings/v8/ScriptController.cpp:187 #24 0xf1564bc3 in WebCore::ScriptController::evaluateScriptInMainWorld (this=0xe7970d88, sourceCode=..., corsStatus=WebCore::NotSharableCrossOrigin, policy=WebCore::ScriptController::DoNotExecuteScriptWhenScriptsDisabled) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/bindings/v8/ScriptController.cpp:582 #25 0xf15649ad in WebCore::ScriptController::executeScriptInMainWorld (this=0xe7970d88, sourceCode=..., corsStatus=WebCore::NotSharableCrossOrigin) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/bindings/v8/ScriptController.cpp:551 #26 0xef763ff0 in WebCore::ScriptLoader::executeScript (this=0xe7972870, sourceCode=...) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/core/dom/ScriptLoader.cpp:335 #27 0xf1d0bf9f in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent (this=0x466e47f0, pendingScript=..., pendingScriptType=WebCore::HTMLScriptRunner::PendingScriptBlockingParser) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp:165 #28 0xf1d0bda0 in WebCore::HTMLScriptRunner::executeParsingBlockingScript (this=0x466e47f0) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp:134 #29 0xf1d0c395 in WebCore::HTMLScriptRunner::executeParsingBlockingScripts (this=0x466e47f0) at ../../../src/3rdparty/chromium/third_party/WebKit/Source/core/html/parser/HTMLScriptRunner.cpp:226 #30 0xf1d0c556 in WebCore::HTMLScriptRunner::executeScriptsWaitingForLoad (this=0x466e47f0, resource=0x467c03d0)