From flying-sheep at web.de  Sat Dec 13 14:06:30 2014
From: flying-sheep at web.de (Philipp A.)
Date: Sat, 13 Dec 2014 14:06:30 +0100
Subject: [Qtwebengine] Dev tools and request signals
Message-ID: <CAN8d9gkVjOkqkT8SucHULYbRYtfFQe5Udoh_y5AT_q0cE_hWqg@mail.gmail.com>

Hi,

I impatiently awaited the new Qt WebEngine, because it has a non-ancient
webkit/blink version and promised to supersede the old Qt Webkit module.

Now how do i enable/trigger the blink dev tools?

And how do i hook into requests the page wants to make without
QNetworkAccessManager interop (in order to find out why the hell that
request was denied even with LocalContentCanAccessRemoteUrls and
LocalContentCanAccessFileUrls)?

if any of the answers are “you don’t”, Qt WebEngine was a bad decision. i
want one thing that is up-to-date and powerful, not thing A that is
deprecated and powerful together with thing B that is up-to-date and inept.

best, philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141213/47e9177a/attachment.html>

From me at the-compiler.org  Sat Dec 13 16:30:00 2014
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 13 Dec 2014 16:30:00 +0100
Subject: [Qtwebengine] Dev tools and request signals
In-Reply-To: <CAN8d9gkVjOkqkT8SucHULYbRYtfFQe5Udoh_y5AT_q0cE_hWqg@mail.gmail.com>
References: <CAN8d9gkVjOkqkT8SucHULYbRYtfFQe5Udoh_y5AT_q0cE_hWqg@mail.gmail.com>
Message-ID: <20141213153000.GV445@tonks>

Hey Philip,

* Philipp A. <flying-sheep at web.de> [2014-12-13 14:06:30 +0100]:
> I impatiently awaited the new Qt WebEngine, because it has a non-ancient
> webkit/blink version and promised to supersede the old Qt Webkit module.
> 
> Now how do i enable/trigger the blink dev tools?
> 
> And how do i hook into requests the page wants to make without
> QNetworkAccessManager interop (in order to find out why the hell that
> request was denied even with LocalContentCanAccessRemoteUrls and
> LocalContentCanAccessFileUrls)?
> 
> if any of the answers are “you don’t”, Qt WebEngine was a bad decision. i
> want one thing that is up-to-date and powerful, not thing A that is
> deprecated and powerful together with thing B that is up-to-date and inept.

I'm not a QtWebEngine developer, just someone writing a browser using
QtWebKit and also looking forward to QtWebEngine. But let me share my
thoughts about this.

The answer to all of this is probably "not yet". This means you can
either patiently wait (what I'm doing), start to contribute, or pay
other people to allow them to work on it more.

That doesn't make QtWebEngine "a bad decision". It's just not there
yet. 5.4 is the first Qt release to include QtWebEngine, you shouldn't
expect to be able to use it for too sophisticated stuff already ;)

That being said, QtWebKit is still being maintained (in terms of
bugfixes) and works just fine for me and a lot of other Qt based
browsers. Nobody said it's deprecated, and I don't expect it to be
deprecated until QtWebEngine is more advanced.

Florian

-- 
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141213/f5760e67/attachment.sig>

From flying-sheep at web.de  Sun Dec 14 00:24:05 2014
From: flying-sheep at web.de (Philipp A.)
Date: Sun, 14 Dec 2014 00:24:05 +0100
Subject: [Qtwebengine] Dev tools and request signals
In-Reply-To: <20141213153000.GV445@tonks>
References: <CAN8d9gkVjOkqkT8SucHULYbRYtfFQe5Udoh_y5AT_q0cE_hWqg@mail.gmail.com>
	<20141213153000.GV445@tonks>
Message-ID: <CAN8d9gnVWjUPTPj9-H1KCUx0xBxVYsvHyAmEJTm8+6RBqgn+7A@mail.gmail.com>

Sorry, i didn’t quite phrase that well:

The decision not to sync Qt Webkit while Qt WebEngine isn’t ready to
replace it yet was a bad decision.

browsers based on Qt now have a lean period during which they can’t ship
proper functionality (newest HTML5 features, as well as cookie, request &
proxy management, dev tools)

2014-12-13 16:30 GMT+01:00 Florian Bruhin <me at the-compiler.org>:
>
> Hey Philip,
>
> * Philipp A. <flying-sheep at web.de> [2014-12-13 14:06:30 +0100]:
> > I impatiently awaited the new Qt WebEngine, because it has a non-ancient
> > webkit/blink version and promised to supersede the old Qt Webkit module.
> >
> > Now how do i enable/trigger the blink dev tools?
> >
> > And how do i hook into requests the page wants to make without
> > QNetworkAccessManager interop (in order to find out why the hell that
> > request was denied even with LocalContentCanAccessRemoteUrls and
> > LocalContentCanAccessFileUrls)?
> >
> > if any of the answers are “you don’t”, Qt WebEngine was a bad decision. i
> > want one thing that is up-to-date and powerful, not thing A that is
> > deprecated and powerful together with thing B that is up-to-date and
> inept.
>
> I'm not a QtWebEngine developer, just someone writing a browser using
> QtWebKit and also looking forward to QtWebEngine. But let me share my
> thoughts about this.
>
> The answer to all of this is probably "not yet". This means you can
> either patiently wait (what I'm doing), start to contribute, or pay
> other people to allow them to work on it more.
>
> That doesn't make QtWebEngine "a bad decision". It's just not there
> yet. 5.4 is the first Qt release to include QtWebEngine, you shouldn't
> expect to be able to use it for too sophisticated stuff already ;)
>
> That being said, QtWebKit is still being maintained (in terms of
> bugfixes) and works just fine for me and a lot of other Qt based
> browsers. Nobody said it's deprecated, and I don't expect it to be
> deprecated until QtWebEngine is more advanced.
>
> Florian
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141214/06351baa/attachment.html>

From jarred at webkit.org  Mon Dec 22 04:56:08 2014
From: jarred at webkit.org (Jarred Nicholls)
Date: Sun, 21 Dec 2014 22:56:08 -0500
Subject: [Qtwebengine] Dev tools and request signals
In-Reply-To: <CAN8d9gnVWjUPTPj9-H1KCUx0xBxVYsvHyAmEJTm8+6RBqgn+7A@mail.gmail.com>
References: <CAN8d9gkVjOkqkT8SucHULYbRYtfFQe5Udoh_y5AT_q0cE_hWqg@mail.gmail.com>
	<20141213153000.GV445@tonks>
	<CAN8d9gnVWjUPTPj9-H1KCUx0xBxVYsvHyAmEJTm8+6RBqgn+7A@mail.gmail.com>
Message-ID: <CANufG2Mdj=6R9v1_tdiQRO2ukyUZapRkcAz0iAkDUvQDksaVLg@mail.gmail.com>

On Sat, Dec 13, 2014 at 6:24 PM, Philipp A. <flying-sheep at web.de> wrote:

> Sorry, i didn’t quite phrase that well:
>
> The decision not to sync Qt Webkit
>

It's not just as easy as a "sync."  It doesn't work like that.  In the
world of WebKit/2, keeping a port up-to-date with the latest functionality
offered by the WebKit engine usually requires some port-specific
implementation.  That means development time and resources.  And the more
development time and resources spent on QtWebKit is less time and resources
spent on QtWebEngine.  Rather than making the trip to QtWebEngine even
longer and more painful of a transition, I believe they are doing the
correct thing and focusing completely on getting the future engine up to
par as quickly as possible.  Unlike Apple and Google, the Digia team does
not have 500 engineers working on their browser.

With that said, I'm not the right person to comment on this decision
because as a Chromium developer, any deficiencies that are currently in
QtWebEngine I've been able to work around in my own fork of it.  I realize
that not everyone has the expertise to do so.  But if I were them, choosing
to spend cycles on the WebKit port would be like eating a bucket of nails
because it is very counter productive to getting QtWebEngine up to feature
parity as quickly as possible.


> while Qt WebEngine isn’t ready to replace it yet was a bad decision.
>
> browsers based on Qt now have a lean period during which they can’t ship
> proper functionality (newest HTML5 features, as well as cookie, request &
> proxy management, dev tools)
>
> 2014-12-13 16:30 GMT+01:00 Florian Bruhin <me at the-compiler.org>:
>
>> Hey Philip,
>>
>> * Philipp A. <flying-sheep at web.de> [2014-12-13 14:06:30 +0100]:
>> > I impatiently awaited the new Qt WebEngine, because it has a non-ancient
>> > webkit/blink version and promised to supersede the old Qt Webkit module.
>> >
>> > Now how do i enable/trigger the blink dev tools?
>> >
>> > And how do i hook into requests the page wants to make without
>> > QNetworkAccessManager interop (in order to find out why the hell that
>> > request was denied even with LocalContentCanAccessRemoteUrls and
>> > LocalContentCanAccessFileUrls)?
>> >
>> > if any of the answers are “you don’t”, Qt WebEngine was a bad decision.
>> i
>> > want one thing that is up-to-date and powerful, not thing A that is
>> > deprecated and powerful together with thing B that is up-to-date and
>> inept.
>>
>> I'm not a QtWebEngine developer, just someone writing a browser using
>> QtWebKit and also looking forward to QtWebEngine. But let me share my
>> thoughts about this.
>>
>> The answer to all of this is probably "not yet". This means you can
>> either patiently wait (what I'm doing), start to contribute, or pay
>> other people to allow them to work on it more.
>>
>> That doesn't make QtWebEngine "a bad decision". It's just not there
>> yet. 5.4 is the first Qt release to include QtWebEngine, you shouldn't
>> expect to be able to use it for too sophisticated stuff already ;)
>>
>> That being said, QtWebKit is still being maintained (in terms of
>> bugfixes) and works just fine for me and a lot of other Qt based
>> browsers. Nobody said it's deprecated, and I don't expect it to be
>> deprecated until QtWebEngine is more advanced.
>>
>> Florian
>>
>> --
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141221/9a2825af/attachment.html>

From longchair69 at gmail.com  Mon Dec 22 15:24:18 2014
From: longchair69 at gmail.com (LongChair69 .)
Date: Mon, 22 Dec 2014 15:24:18 +0100
Subject: [Qtwebengine] Build QtWebEngine on RaspBerry Pi
In-Reply-To: <20141119124138.GK32338@tonks>
References: <CACSKecKRqUZ+kzG3dPTTw+HpHpPOo_-Q4m=w4L0tgV-1TN+wEQ@mail.gmail.com>
	<20141118065602.GB32338@tonks>
	<CACSKecLxzfuJorMWHGzXjrPpG42zsW70M3z06MUA7du8wU0oJg@mail.gmail.com>
	<20141119124138.GK32338@tonks>
Message-ID: <CACSKecLe6c+y--V5Pyg-iR-+Q=Bm1GpuR6DoDkinqQavpjb6DA@mail.gmail.com>

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 <me at the-compiler.org>:

> * LongChair69 . <longchair69 at gmail.com> [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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141222/2183aba1/attachment.html>

From davecortesi at gmail.com  Tue Dec 30 02:28:19 2014
From: davecortesi at gmail.com (David Cortesi)
Date: Mon, 29 Dec 2014 17:28:19 -0800
Subject: [Qtwebengine] Hopeful of a timeline?
Message-ID: <CALyzANto4uEnYRijBAfd9dypTFYsDyMQxky3Nf4m423N_WbT1A@mail.gmail.com>

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
> <http://doc.qt.io/qt-5/qtwebengine-index.html> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20141229/8197bcf9/attachment.html>