From Simon.Hausmann at digia.com  Wed Feb  5 18:15:56 2014
From: Simon.Hausmann at digia.com (Hausmann Simon)
Date: Wed, 5 Feb 2014 17:15:56 +0000
Subject: [Qtwebengine] transport mechanisms for QWebChannel
Message-ID: <9160F3295FA8E24781968BBD40362991011513B5@IT-EXMB01-HKI.it.local>

Hi,

I've been thinking about whole situation with pluggable transport channels for
QWebChannel again, and I have an suggestion: Let's get rid of QWebChannel ;-)

1) I think if somebody wants to send plain messages back and forth between QML
and web content using web sockets, then Qt's WebSocket QML API should be
designed in a way that makes this trivial and easy:

WebSocketServer {
    id: webSocket
    onNewConnectionRequest: {
        var connection = request.accept()
        connection.onMessage = function() { print("hey"); }
    }
}

and then maybe the server object has a serverUrl property that can be passed to
web content.  There's a design challenge there, but fundamentally I think it
belongs there.

2) As you can see in the recent threads on chromium-dev, the concept of sending
messages between web content and an embedded web view in native code is also an
increasingly interesting use-case, and native APIs are getting support for it.
And therefore the postMessage approach we've had in the WebKit2 WebView is
great and it would be lovely to have something similar in the WebEngineView. We
should advocate it and tell people to use it if they can.

3) Maybe I'd like to expose entire objects to web content, and for that perhaps we should have something like this:

WebObjectBridge {
    id: bridge

    /* in implementation:
    property list<QtObject> bridgedObjects;
    default property alias bridgedChildren: bridgedObjects; // work around grammar limitation
    */
}

Then I can write:

WebObjectBridge {
    id: bridge

    QtObject {
        id: firstExposedObject
    }
    QtObject {
        id: anotherObject
    }
}

as well as

    bridge.bridgedObjects.append(myDynamicObject);


Now the next question is: How do we connect the WebObjectBridge with web
content?  This is where I would like to be able to just write:

WebObjectBridge {
    id: bridge
    ...
    connections: [ webView1, webView2, ... ]
}

This would use a webView built-in fast and secure transport mechanism. At the
same time maybe I'd also like to connect it to a web socket transport:

WebSocketServer {
    id: wss
    onNewConnectionRequest: {
        var connection = request.accept();
        bridge.connections.append(connection);
    }
}

WebObjectBridge {
    id: bridge
}

The ability of the Qml engine to deal with interfaces might be sufficient to
allow for this to work, i.e. that WebEngineView's C++ implementation also
implements the corresponding Qt C++ interface and so would the web socket,
without having an actual dependency to the WebObjectBridge implementation.


What do you think?


Simon


From milian.wolff at kdab.com  Thu Feb  6 13:18:41 2014
From: milian.wolff at kdab.com (Milian Wolff)
Date: Thu, 06 Feb 2014 13:18:41 +0100
Subject: [Qtwebengine] transport mechanisms for QWebChannel
In-Reply-To: <9160F3295FA8E24781968BBD40362991011513B5@IT-EXMB01-HKI.it.local>
References: <9160F3295FA8E24781968BBD40362991011513B5@IT-EXMB01-HKI.it.local>
Message-ID: <4363293.ysE83rrLKj@milian-kdab2>

On Wednesday 05 February 2014 17:15:56 Hausmann Simon wrote:
> Hi,

Hey Simon!

> I've been thinking about whole situation with pluggable transport channels
> for QWebChannel again, and I have an suggestion: Let's get rid of
> QWebChannel ;-)

I'm all ears.

> 1) I think if somebody wants to send plain messages back and forth between
> QML and web content using web sockets, then Qt's WebSocket QML API should
> be designed in a way that makes this trivial and easy:
> 
> WebSocketServer {
>     id: webSocket
>     onNewConnectionRequest: {
>         var connection = request.accept()
>         connection.onMessage = function() { print("hey"); }
>     }
> }
> 
> and then maybe the server object has a serverUrl property that can be passed
> to web content.  There's a design challenge there, but fundamentally I
> think it belongs there.
> 
> 2) As you can see in the recent threads on chromium-dev, the concept of
> sending messages between web content and an embedded web view in native
> code is also an increasingly interesting use-case, and native APIs are
> getting support for it. And therefore the postMessage approach we've had in
> the WebKit2 WebView is great and it would be lovely to have something
> similar in the WebEngineView. We should advocate it and tell people to use
> it if they can.

I completely agree with these two points. The more I refactored the current 
QWebChannel code, the less I feel it makes "sense". If you want to use 
websockets, one would use QtWebSockets now. For direct IPC, use the 
WebView.experimental API. So the "simple" message passing nature of the 
webchannel is simply obsolete by now. Currently it just gives a nice 
abstracted API which can be used by both WebSockets and WebView IPC 
transparently.

> 3) Maybe I'd like to expose entire objects to web content, and for that
> perhaps we should have something like this:
> 
> WebObjectBridge {
>     id: bridge
> 
>     /* in implementation:
>     property list<QtObject> bridgedObjects;
>     default property alias bridgedChildren: bridgedObjects; // work around
> grammar limitation */
> }
> 
> Then I can write:
> 
> WebObjectBridge {
>     id: bridge
> 
>     QtObject {
>         id: firstExposedObject
>     }
>     QtObject {
>         id: anotherObject
>     }
> }
> 
> as well as
> 
>     bridge.bridgedObjects.append(myDynamicObject);

As well as

WebObjectBridge {
  bridgedObjects: [foo, bar, baz]
}

right? Assuming foo, bar and baz are defined somewhere else?

> Now the next question is: How do we connect the WebObjectBridge with web
> content?  This is where I would like to be able to just write:
> 
> WebObjectBridge {
>     id: bridge
>     ...
>     connections: [ webView1, webView2, ... ]
> }
> 
> This would use a webView built-in fast and secure transport mechanism. At
> the same time maybe I'd also like to connect it to a web socket transport:
> 
> WebSocketServer {
>     id: wss
>     onNewConnectionRequest: {
>         var connection = request.accept();
>         bridge.connections.append(connection);
>     }
> }
> 
> WebObjectBridge {
>     id: bridge
> }
> 
> The ability of the Qml engine to deal with interfaces might be sufficient to
> allow for this to work, i.e. that WebEngineView's C++ implementation also
> implements the corresponding Qt C++ interface and so would the web socket,
> without having an actual dependency to the WebObjectBridge implementation.
> 
> 
> What do you think?

I like it. And its naturally following out of the recent refactoring to allow 
a pluggable transport mechanism imo [1].

Note that this actually does not require much changes, when you replace 
WebObjectBridge with WebChannel it mostly works even now. Whats missing is the 
removal of the "raw message passing" API and pushing the transport interface 
into QtWebKit, QtWebSockets and QtWebEngine modules.

So generally, I'd say we continue to integrate the existing patch [1]. I'll 
now experiment with moving the transport interface to another module and see 
how it works. Removing the raw API later on and potentially renaming the 
WebChannel can follow.

[1]: https://codereview.qt-project.org/#change,75597

Bye
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions



From simon.hausmann at digia.com  Thu Feb  6 13:22:16 2014
From: simon.hausmann at digia.com (Simon Hausmann)
Date: Thu, 6 Feb 2014 13:22:16 +0100
Subject: [Qtwebengine] transport mechanisms for QWebChannel
In-Reply-To: <4363293.ysE83rrLKj@milian-kdab2>
References: <9160F3295FA8E24781968BBD40362991011513B5@IT-EXMB01-HKI.it.local>
	<4363293.ysE83rrLKj@milian-kdab2>
Message-ID: <3322716.ZoVlSrRQcv@rhea>

On Thursday 6. February 2014 13.18.41 Milian Wolff wrote:
> On Wednesday 05 February 2014 17:15:56 Hausmann Simon wrote:
> > Hi,
> 
> Hey Simon!
> 
> > I've been thinking about whole situation with pluggable transport channels
> > for QWebChannel again, and I have an suggestion: Let's get rid of
> > QWebChannel ;-)
> 
> I'm all ears.
> 
> > 1) I think if somebody wants to send plain messages back and forth between
> > QML and web content using web sockets, then Qt's WebSocket QML API should
> > be designed in a way that makes this trivial and easy:
> > 
> > WebSocketServer {
> > 
> >     id: webSocket
> >     onNewConnectionRequest: {
> >     
> >         var connection = request.accept()
> >         connection.onMessage = function() { print("hey"); }
> >     
> >     }
> > 
> > }
> > 
> > and then maybe the server object has a serverUrl property that can be
> > passed to web content.  There's a design challenge there, but
> > fundamentally I think it belongs there.
> > 
> > 2) As you can see in the recent threads on chromium-dev, the concept of
> > sending messages between web content and an embedded web view in native
> > code is also an increasingly interesting use-case, and native APIs are
> > getting support for it. And therefore the postMessage approach we've had
> > in
> > the WebKit2 WebView is great and it would be lovely to have something
> > similar in the WebEngineView. We should advocate it and tell people to use
> > it if they can.
> 
> I completely agree with these two points. The more I refactored the current
> QWebChannel code, the less I feel it makes "sense". If you want to use
> websockets, one would use QtWebSockets now. For direct IPC, use the
> WebView.experimental API. So the "simple" message passing nature of the
> webchannel is simply obsolete by now. Currently it just gives a nice
> abstracted API which can be used by both WebSockets and WebView IPC
> transparently.

Yep, that's the key insight.

> > 3) Maybe I'd like to expose entire objects to web content, and for that
> > perhaps we should have something like this:
> > 
> > WebObjectBridge {
> > 
> >     id: bridge
> >     
> >     /* in implementation:
> >     property list<QtObject> bridgedObjects;
> >     default property alias bridgedChildren: bridgedObjects; // work around
> > 
> > grammar limitation */
> > }
> > 
> > Then I can write:
> > 
> > WebObjectBridge {
> > 
> >     id: bridge
> >     
> >     QtObject {
> >     
> >         id: firstExposedObject
> >     
> >     }
> >     QtObject {
> >     
> >         id: anotherObject
> >     
> >     }
> > 
> > }
> > 
> > as well as
> > 
> >     bridge.bridgedObjects.append(myDynamicObject);
> 
> As well as
> 
> WebObjectBridge {
>   bridgedObjects: [foo, bar, baz]
> }
> 
> right? Assuming foo, bar and baz are defined somewhere else?

Oh yeah.
 
> > Now the next question is: How do we connect the WebObjectBridge with web
> > content?  This is where I would like to be able to just write:
> > 
> > WebObjectBridge {
> > 
> >     id: bridge
> >     ...
> >     connections: [ webView1, webView2, ... ]
> > 
> > }
> > 
> > This would use a webView built-in fast and secure transport mechanism. At
> > the same time maybe I'd also like to connect it to a web socket transport:
> > 
> > WebSocketServer {
> > 
> >     id: wss
> >     onNewConnectionRequest: {
> >     
> >         var connection = request.accept();
> >         bridge.connections.append(connection);
> >     
> >     }
> > 
> > }
> > 
> > WebObjectBridge {
> > 
> >     id: bridge
> > 
> > }
> > 
> > The ability of the Qml engine to deal with interfaces might be sufficient
> > to allow for this to work, i.e. that WebEngineView's C++ implementation
> > also implements the corresponding Qt C++ interface and so would the web
> > socket, without having an actual dependency to the WebObjectBridge
> > implementation.
> > 
> > 
> > What do you think?
> 
> I like it. And its naturally following out of the recent refactoring to
> allow a pluggable transport mechanism imo [1].
> 
> Note that this actually does not require much changes, when you replace
> WebObjectBridge with WebChannel it mostly works even now. Whats missing is
> the removal of the "raw message passing" API and pushing the transport
> interface into QtWebKit, QtWebSockets and QtWebEngine modules.

Yup, largely a renaming exercise.
 
> So generally, I'd say we continue to integrate the existing patch [1]. I'll
> now experiment with moving the transport interface to another module and see
> how it works. Removing the raw API later on and potentially renaming the
> WebChannel can follow.
> 
> [1]: https://codereview.qt-project.org/#change,75597

Okay, then I'll review that and we proceed from there.


Simon


From mchishtie at gmail.com  Fri Feb 14 00:53:56 2014
From: mchishtie at gmail.com (Mansoor C)
Date: Thu, 13 Feb 2014 17:53:56 -0600
Subject: [Qtwebengine] Video texture streaming
Message-ID: <CACDZ4pKQ6mON+to0-BqkX1ScD1e3HriTN9SQhyhpPdL9uO66Sg@mail.gmail.com>

Hi All:

Here at BlackBerry we have been developing support for EGLImage based
video texture streaming for QtWebEngine/QNX. It adds a new
StreamVideoNode class similar to the existing YUVVideoNode class. It
also adds support for new cc::DrawQuad::STREAM_VIDEO_CONTENT material
in DelegatedFrameNode.

We have this working successfully in our QtWebEngine test app on QNX platform.

I have pushed a clean patch for gerrit review here:
https://codereview.qt-project.org/#change,78138

For now I have put Jocelyn and Arvid as reviewers. I am not sure who
else should be looking at it.

I have intentionally tried to keep changes localized to QtWebEngine -
and not mess with QSG APIs. But if there are better ways to implement
this, I am open to your suggestions.

Thanks,
Mansoor


From Simon.Hausmann at digia.com  Fri Feb 14 01:44:52 2014
From: Simon.Hausmann at digia.com (Hausmann Simon)
Date: Fri, 14 Feb 2014 00:44:52 +0000
Subject: [Qtwebengine] Video texture streaming
In-Reply-To: <CACDZ4pKQ6mON+to0-BqkX1ScD1e3HriTN9SQhyhpPdL9uO66Sg@mail.gmail.com>
References: <CACDZ4pKQ6mON+to0-BqkX1ScD1e3HriTN9SQhyhpPdL9uO66Sg@mail.gmail.com>
Message-ID: <20140214004451.5288070.97192.4912@digia.com>

Conceptually I think this makes a lot of sense. This type of fragment shader is also in chromium's GL renderer and a sensible optimization if the GPU supports it (as opposed to doing the color space conversion manually in the shader)

This patch is on no way blackberry specific and for example relevant for embedded Linux builds with OpenMax IL backend and for example PowerVR gpu.


Simon

  Opprinnelig melding
Fra: Mansoor C
Sendt: 16:54 torsdag 13. februar 2014
Til: qtwebengine at qt-project.org
Emne: [Qtwebengine] Video texture streaming


Hi All:

Here at BlackBerry we have been developing support for EGLImage based
video texture streaming for QtWebEngine/QNX. It adds a new
StreamVideoNode class similar to the existing YUVVideoNode class. It
also adds support for new cc::DrawQuad::STREAM_VIDEO_CONTENT material
in DelegatedFrameNode.

We have this working successfully in our QtWebEngine test app on QNX platform.

I have pushed a clean patch for gerrit review here:
https://codereview.qt-project.org/#change,78138

For now I have put Jocelyn and Arvid as reviewers. I am not sure who
else should be looking at it.

I have intentionally tried to keep changes localized to QtWebEngine -
and not mess with QSG APIs. But if there are better ways to implement
this, I am open to your suggestions.

Thanks,
Mansoor
_______________________________________________
QtWebEngine mailing list
QtWebEngine at qt-project.org
http://lists.qt-project.org/mailman/listinfo/qtwebengine


From mchishtie at gmail.com  Thu Feb 20 01:16:13 2014
From: mchishtie at gmail.com (Mansoor C)
Date: Wed, 19 Feb 2014 18:16:13 -0600
Subject: [Qtwebengine] Help with Linux desktop build
Message-ID: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>

Hi,

I am trying to build upstream Linux desktop version (per Jocelyn's
suggestion) to verify that my texture streaming patch builds properly.
This is the first time I am trying to build upstream directly.

I was able to clone, configure, and build upstream qt5 using
directions here - no errors
http://qt-project.org/wiki/Building-Qt-5-from-Git. I checked out stable branch.

I was also able to clone qtwebengine upstream following directions from here:
https://qt.gitorious.org/qt-labs/qtwebengine/source/e0653be7a315dc0b66af35c340a094de8a284117:

However, 'qmake -r' can't find quick or qml modules.

mchishtie at mansoor-rim:/media/ssd/upstream/qtwebengine$
/media/ssd/upstream/qt5/qtbase/bin/qmake -r
Info: creating cache file /media/ssd/upstream/qtwebengine/.qmake.cache
Reading /media/ssd/upstream/qtwebengine/src/src.pro
 Reading /media/ssd/upstream/qtwebengine/src/core/core.pro
  Reading /media/ssd/upstream/qtwebengine/src/core/core_gyp_generator.pro
Project ERROR: Unknown module(s) in QT: quick qml

Am I not configuring/building Qt5 correctly?

Thanks, Mansoor

P.S. Here are my steps:


git clone https://git.gitorious.org/qt/qt5.git qt5
cd qt5
git checkout stable
perl init-repository --no-webkit --http --codereview-username mchishtie
./configure -qt-xcb -developer-build -opensource -nomake examples -nomake tests
make -j8

git clone https://git.gitorious.org/qt-labs/qtwebengine.git
cd qtwebengine
git submodule init && git submodule update --recursive
qmake -r [note 'qmake' works but then fails at 'make']


From sahumada at blackberry.com  Thu Feb 20 09:16:08 2014
From: sahumada at blackberry.com (Sergio Ahumada)
Date: Thu, 20 Feb 2014 09:16:08 +0100
Subject: [Qtwebengine] Help with Linux desktop build
In-Reply-To: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>
References: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>
Message-ID: <5305B9C8.5040502@blackberry.com>

On 20.02.2014 01:16, Mansoor C wrote:
> Hi,
>
> I am trying to build upstream Linux desktop version (per Jocelyn's
> suggestion) to verify that my texture streaming patch builds properly.
> This is the first time I am trying to build upstream directly.
>
> P.S. Here are my steps:
>
>
> git clone https://git.gitorious.org/qt/qt5.git qt5
> cd qt5
> git checkout stable
> perl init-repository --no-webkit --http --codereview-username mchishtie
> ./configure -qt-xcb -developer-build -opensource -nomake examples -nomake tests

could you please try:

./configure -prefix $PWD/qtbase -qt-xcb -developer-build -opensource 
-nomake examples -nomake tests

and see if that helps ?

-- 
Sergio Ahumada
sahumada at blackberry.com


From jocelyn.turcotte at digia.com  Thu Feb 20 11:36:39 2014
From: jocelyn.turcotte at digia.com (Jocelyn Turcotte)
Date: Thu, 20 Feb 2014 11:36:39 +0100
Subject: [Qtwebengine] Help with Linux desktop build
In-Reply-To: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>
References: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>
Message-ID: <20140220103639.GA13042@poutine.it.local>

On Wed, Feb 19, 2014 at 06:16:13PM -0600, Mansoor C wrote:
> Hi,
> 
> I am trying to build upstream Linux desktop version (per Jocelyn's
> suggestion) to verify that my texture streaming patch builds properly.
> This is the first time I am trying to build upstream directly.
> 
> I was able to clone, configure, and build upstream qt5 using
> directions here - no errors
> http://qt-project.org/wiki/Building-Qt-5-from-Git. I checked out stable branch.
> 
> I was also able to clone qtwebengine upstream following directions from here:
> https://qt.gitorious.org/qt-labs/qtwebengine/source/e0653be7a315dc0b66af35c340a094de8a284117:
> 
> However, 'qmake -r' can't find quick or qml modules.
> 
> mchishtie at mansoor-rim:/media/ssd/upstream/qtwebengine$
> /media/ssd/upstream/qt5/qtbase/bin/qmake -r
> Info: creating cache file /media/ssd/upstream/qtwebengine/.qmake.cache
> Reading /media/ssd/upstream/qtwebengine/src/src.pro
>  Reading /media/ssd/upstream/qtwebengine/src/core/core.pro
>   Reading /media/ssd/upstream/qtwebengine/src/core/core_gyp_generator.pro
> Project ERROR: Unknown module(s) in QT: quick qml
> 
> Am I not configuring/building Qt5 correctly?

This usually means that either the qtdeclarative submodule isn't initialized (unlikely) or that the build in qtdeclarative failed and you didn't notice (happens to me from time to time). The qtdeclarative build should produces qt_lib_quick.pri and qt_lib_qml.pri module files in qtbase/mkspecs/modules, else you'll get this error when trying to use the module.

So additionally to Sergio's trick, you can try to re-run make in /media/ssd/upstream/qt5/qtdeclarative and make sure that it succeeds.

Note that if you use the -developer-build configure switch you can use the /media/ssd/upstream/qt5/qtbase/bin/qmake directly, but if you don't use it and use a -prefix, you should do make install and use $prefix/bin/qmake instead.

Hoping this helps,
Cheers,
Jocelyn



From mchishtie at gmail.com  Fri Feb 21 00:06:57 2014
From: mchishtie at gmail.com (Mansoor C)
Date: Thu, 20 Feb 2014 17:06:57 -0600
Subject: [Qtwebengine] Help with Linux desktop build
In-Reply-To: <20140220103639.GA13042@poutine.it.local>
References: <CACDZ4pLXj6Q+=y4rxb4kGma6Cfa=+2eh6Ytwb0x0VN=6=fjiKg@mail.gmail.com>
	<20140220103639.GA13042@poutine.it.local>
Message-ID: <CACDZ4pK=6YJLqFFpHhe=Abx-9ai=dyeO=f-Gp+QGjqFz9owsNg@mail.gmail.com>

Thanks Sergio and Jocelyn for help!

The problem indeed was that qtdecl was not building quick and qml
modules. When I did 'make module-qtdeclarative' in /qt5, it did build
the modules successfully. I am not sure why my original 'make' failed
to build completely ... but it now works.

I've uploaded patch set 4 (external texture streaming) for Jocelyn et
al to review.

Thanks, Mansoor

On Thu, Feb 20, 2014 at 4:36 AM, Jocelyn Turcotte
<jocelyn.turcotte at digia.com> wrote:
> On Wed, Feb 19, 2014 at 06:16:13PM -0600, Mansoor C wrote:
>> Hi,
>>
>> I am trying to build upstream Linux desktop version (per Jocelyn's
>> suggestion) to verify that my texture streaming patch builds properly.
>> This is the first time I am trying to build upstream directly.
>>
>> I was able to clone, configure, and build upstream qt5 using
>> directions here - no errors
>> http://qt-project.org/wiki/Building-Qt-5-from-Git. I checked out stable branch.
>>
>> I was also able to clone qtwebengine upstream following directions from here:
>> https://qt.gitorious.org/qt-labs/qtwebengine/source/e0653be7a315dc0b66af35c340a094de8a284117:
>>
>> However, 'qmake -r' can't find quick or qml modules.
>>
>> mchishtie at mansoor-rim:/media/ssd/upstream/qtwebengine$
>> /media/ssd/upstream/qt5/qtbase/bin/qmake -r
>> Info: creating cache file /media/ssd/upstream/qtwebengine/.qmake.cache
>> Reading /media/ssd/upstream/qtwebengine/src/src.pro
>>  Reading /media/ssd/upstream/qtwebengine/src/core/core.pro
>>   Reading /media/ssd/upstream/qtwebengine/src/core/core_gyp_generator.pro
>> Project ERROR: Unknown module(s) in QT: quick qml
>>
>> Am I not configuring/building Qt5 correctly?
>
> This usually means that either the qtdeclarative submodule isn't initialized (unlikely) or that the build in qtdeclarative failed and you didn't notice (happens to me from time to time). The qtdeclarative build should produces qt_lib_quick.pri and qt_lib_qml.pri module files in qtbase/mkspecs/modules, else you'll get this error when trying to use the module.
>
> So additionally to Sergio's trick, you can try to re-run make in /media/ssd/upstream/qt5/qtdeclarative and make sure that it succeeds.
>
> Note that if you use the -developer-build configure switch you can use the /media/ssd/upstream/qt5/qtbase/bin/qmake directly, but if you don't use it and use a -prefix, you should do make install and use $prefix/bin/qmake instead.
>
> Hoping this helps,
> Cheers,
> Jocelyn
>


From Rich.Conlan at mathworks.com  Thu Feb 27 15:57:39 2014
From: Rich.Conlan at mathworks.com (Rich Conlan)
Date: Thu, 27 Feb 2014 14:57:39 +0000
Subject: [Qtwebengine] QtWebEngine current status?
Message-ID: <47dc9031a13049b3a3cd5f59a1a6355e@ex13amer-00-ah.ad.mathworks.com>

Greetings,

I was just perusing http://qt-project.org/wiki/New-Features-in-Qt-5.3 and noticed that it makes no mention of QWebEngine, even as preview support. Does anybody know the status of how that's moving along? Is it no longer expected to be integrated enough to be part of 5.3?

http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/ is the latest info I can find. Mostly I'm trying to keep up on the progress here as I want to switch from QtWebKit to QtWebEngine as soon as it's available. I imagine it's quite an anticipated feature, but I'm having trouble finding much info on how it's going. Any insights you can provide are appreciated,

R.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20140227/ab7c3737/attachment.html>

From nicolas.dechesne at linaro.org  Thu Feb 27 16:55:46 2014
From: nicolas.dechesne at linaro.org (Nicolas Dechesne)
Date: Thu, 27 Feb 2014 16:55:46 +0100
Subject: [Qtwebengine] QtWebEngine current status?
In-Reply-To: <47dc9031a13049b3a3cd5f59a1a6355e@ex13amer-00-ah.ad.mathworks.com>
References: <47dc9031a13049b3a3cd5f59a1a6355e@ex13amer-00-ah.ad.mathworks.com>
Message-ID: <CAP71WjzWyuFjiUS8k_QDkBDeb6TYzx5JPThU39SYi-UUWWKhWw@mail.gmail.com>

On Thu, Feb 27, 2014 at 3:57 PM, Rich Conlan <Rich.Conlan at mathworks.com> wrote:
> I was just perusing http://qt-project.org/wiki/New-Features-in-Qt-5.3 and
> noticed that it makes no mention of QWebEngine, even as preview support.
> Does anybody know the status of how that's moving along? Is it no longer
> expected to be integrated enough to be part of 5.3?
>
>
>
> http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/
> is the latest info I can find. Mostly I'm trying to keep up on the progress
> here as I want to switch from QtWebKit to QtWebEngine as soon as it's
> available. I imagine it's quite an anticipated feature, but I'm having
> trouble finding much info on how it's going. Any insights you can provide
> are appreciated,
>

I am interested about that too. Especially about any progress/update
on QtWebEngine + EGLFS.

cheers

nico


From Zeno.Albisser at digia.com  Thu Feb 27 23:16:37 2014
From: Zeno.Albisser at digia.com (Albisser Zeno)
Date: Thu, 27 Feb 2014 22:16:37 +0000
Subject: [Qtwebengine] QtWebEngine current status?
In-Reply-To: <47dc9031a13049b3a3cd5f59a1a6355e@ex13amer-00-ah.ad.mathworks.com>
Message-ID: <CF35632C.86EF%zeno.albisser@digia.com>

Hi,

I was just perusing http://qt-project.org/wiki/New-Features-in-Qt-5.3 and noticed that it makes no mention of QWebEngine, even as preview support. Does anybody know the status of how that’s moving along? Is it no longer expected to be integrated enough to be part of 5.3?

The feature freeze for 5.3 was way too early to make it in with QtWebEngine. However, already with the last blog post we mentioned that we are planning on having alpha and/or beta releases in first half of 2014. And this is still our plan. The exact naming for our first release is still subject of discussions. It might be an alpha, a beta or simply a 1.0 release. - But finally, this is really just naming.


http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/ is the latest info I can find. Mostly I’m trying to keep up on the progress here as I want to switch from QtWebKit to QtWebEngine as soon as it’s available. I imagine it’s quite an anticipated feature, but I’m having trouble finding much info on how it’s going. Any insights you can provide are appreciated,

This is the latest info that we published in a blog form, that is correct. :-)
If you require more recent information you might want to keep an eye on our channel #qtwebengine on freenode, take a look at our trello board https://trello.com/b/5G9c1rkb or simply follow the commits in our repo https://qt.gitorious.org/qt-labs/qtwebengine/commits .

We have QtWebEngine working already pretty well with Linux and Mac OSX. If these platforms are what you need, I would suggest to compile it and give it a try. Feel free to let us know which particular features you are missing. - We appreciate getting feedback.

- Zeno

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20140227/09a4a37f/attachment.html>

From Zeno.Albisser at digia.com  Thu Feb 27 23:29:39 2014
From: Zeno.Albisser at digia.com (Albisser Zeno)
Date: Thu, 27 Feb 2014 22:29:39 +0000
Subject: [Qtwebengine] QtWebEngine current status?
In-Reply-To: <CAP71WjzWyuFjiUS8k_QDkBDeb6TYzx5JPThU39SYi-UUWWKhWw@mail.gmail.com>
Message-ID: <CF3569E5.872E%zeno.albisser@digia.com>

Hi,

On 2/27/14, 3:55 PM, "Nicolas Dechesne" <nicolas.dechesne at linaro.org>
wrote:
>
>I am interested about that too. Especially about any progress/update
>on QtWebEngine + EGLFS.

Adding support for Qt Enterprise Embedded Android and QtEE Linux is
currently our main focus. Both are using EGLFS.
QtEE Android is already looking pretty good. With QtEE Linux we have been
loading our first web pages as well, but there is still a bit of work left
on that side.
Further we are also working on adding support for Windows and on providing
a more complete API for Widgets and QtQuick.

- Zeno



From eugene.sobol at gmail.com  Fri Feb 28 11:52:26 2014
From: eugene.sobol at gmail.com (Eugene Sobol)
Date: Fri, 28 Feb 2014 13:52:26 +0300
Subject: [Qtwebengine] Help with Linux desktop build
Message-ID: <CAKwbzcwC_5mwi=W02dVf-xgwyPUytZp1b74p-v6UCSCN-dHPug@mail.gmail.com>

Hello.
I encountered with following problem during build for Linux desktop:

i -fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare  -c
../../src/3rdparty/chromium/base/message_loop/message_loop.cc -o
obj/src/3rdparty/chromium/base/message_loop/base.message_loop.o
../../src/3rdparty/chromium/base/message_loop/message_loop.cc:37:21: fatal
error: gdk/gdk.h: No such file or directory
 #include <gdk/gdk.h>
                     ^
compilation terminated.

I am going to cross compile it on system without gtk, but I also can't
build it without gtk on desktop.

Could you please recomend some solutions to avoid that issue?

Used build instructions at:
https://qt.gitorious.org/qt-labs/qtwebengine/source/ecaab295f96e3d12fc952c49d35a6eb32f72aba1:README.md

Qt5.2.1/Qt5.2.0 from:
http://qt-project.org/downloads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20140228/fa2b41e4/attachment.html>