Discussion:
Qt for WebAssembly
(too old to reply)
Morten Sørvig
2018-03-09 12:57:49 UTC
Permalink
Hi all,

As you may have noticed work on Qt for WebAssembly is underway. With the
recent updates the wip/webassembly branches are now based on Qt 5.11, which
they will continue to be while we work on bringing up Qt Quick. The tracking
bug for the project is QTBUG-63917 (with subtasks). This is a continuation of
the initial port at https://codereview.qt-project.org/#/c/178543/

I think this may be a good time to discuss how we want to support Qt for
WebAssembly and what direction the project should take. I’ll start out
by describing some recent developments:

* We are targeting WebAssembly using Emscripten as the SDK. The platform plugin
is implemented (mainly) using the html5.h API from emscripten.

The platform define is Q_OS_HTML5. We have wip branches for qtbase and
qtdeclarative. If (minor) adjustments are needed in other modules then
those could be submitted to the 5.11 branch under the Q_OS_HTML5 define.

* Binary sizes: We are using static builds. The minimal Qt demos (QtCore + QtGui) come
out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + QtQuick + QtCharts)
(as seen on Embedded World) is 6.3M.

In the end it may be that application assets will contribute significantly to
the overall application size. We can look into building an asset download
pipeline using web service workers.

* Load times: In addition to the network connection this depends on the browser
wasm implementation, Firefox has recently gotten very fast and can download and
instantiate the small Qt demos in a couple of seconds.

* Qt Applications as web page components

Qt for WebAssembly draws to a HTML <canvas> element. The default Qt html template
makes the canvas cover the entire browser viewport, but any layout is possible.
The size and position of the canvas may very well be outside of the applications
control. Multiple canvases per “process” is possible but not yet supported.

On the Qt side each canvas corresponds to a QScreen. The application is responsible
for positioning windows on the screen(s). Qt::WindowFullScreen windows fill the entire
canvas area with application content, normal windows get window decorations.

We provide a Javascript API (qtloader.js) for managing the application process.
(Here we have the luxury of using modern JS features due to the natural selection
of browsers that the wasm requirement provides.)

* Fonts

We don’t have access to system font files. This means fonts must me embedded in
the application binary or downloaded on demand.

Exact font style matches with “native” system fonts will probably remain out of
scope, but should still be able to match the font size setting. Page zoom is
handled via the high-dpi implementation.

* (No) thread support

Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer,
which has been disabled in all major browser after recent security incidents.

So we are looking to upstream a no-thread configure option, and modules that
want to work on the web should support it. It’s still possible to develop with
pthreads enabled by enabling SharedArrayBuffer for your browser.

No-thread could be implemented either by removing QThread (and friends), or by
making QThread::start() a no-op.

* QML interpretation vs compilation

We’re currently using the QML interpreter, which is working reasonably well
for development purposes. The end state is to compile to wasm, ahead of time.

There has been some discussion on whether compilation should be implemented
before anything is merged to the main Qt branches, or be handled later on.

* Networking

We are looking there approaches: (not mutually exclusive)

- A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch.

This allows making HTTP REST requests back to the origin server, or to other servers
by using CORS.

- A QWebSocket (client) backend implemented using HTML5 WebSocket

This would allow making websocket connections to any server.

- Using the emscripten sockets implementation and websockify.

This is a tunneling solution where the server runs e.g. websockify and will forward
to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work
is needed in Qt.

* QtMultimedia

Very open for contributions :)

Further information including getting started instructions is available on QTBUG-63917,
and also or on QTBUG-65198 (platform documentation).

Thanks for reading!
Morten
Jason H
2018-03-09 14:53:54 UTC
Permalink
<box type="soap">
While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable.
After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb).

While I wish you the best of luck, I don't think it's going to work out well. The other day I asked the question on the blog, "Why can't we divorce behavior from the the UI?" (conceptually speaking) I was asking it in the context of QtQuick/QWidgets consistency, but I'd like to extend that to HTML elements as well. You should be able to define the UI component and the behavior component of a GUI item seperately and just attach the same behaviors to he various UIs. The thing here is that the HTML version of it would already come with some behaviors supplied by the browser, and the UI component would similarly be rendered by the browser. I know this isn't do-able in 5, or maybe even 6, but it's where I think things are headed.

For example, a simple .ui file translator that gives you a HTML5 app would be the start. If you don't think this is possible, you should check out Webtoolkit (https://www.webtoolkit.eu/wt) which is a copy of Qt for the web. It works. At one point I wrote a script t translate Designer's .ui files from the Q* to the W* versions and it worked, mostly. If Qt wants to target the web, properly then bringing in Wt would be the 'proper' (IMHO) approach.

We've had efforts to cram Qt binaries into browsers for over 10 years now (ActiveQt). None of it has really succeeded. I speculate it's because the initial load time is a huge turn-off. You can't use Qt for regular web sites, soo the appeal is limited. The ideal approach is one where Qt is advanced as a preferred web development technology, as well as a native technology. Incidentally that also opens Qt up to the biggest possible licensing base.
Qt can compete with (and IMHO is better than) React and Angular. But this smallest-effort-to-the-browser is fundamentally broken, and I think will only result in an "also-ran" situation.

I don't want to steal your thunder, but what is fundamentally different about this approach this time? Why will the results be any different?
</box>



> Sent: Friday, March 09, 2018 at 7:57 AM
> From: "Morten Sørvig" <***@qt.io>
> To: "Qt Project Development Mailing-List" <***@qt-project.org>
> Subject: [Development] Qt for WebAssembly
>
> Hi all,
>
> As you may have noticed work on Qt for WebAssembly is underway. With the
> recent updates the wip/webassembly branches are now based on Qt 5.11, which
> they will continue to be while we work on bringing up Qt Quick. The tracking
> bug for the project is QTBUG-63917 (with subtasks). This is a continuation of
> the initial port at https://codereview.qt-project.org/#/c/178543/
>
> I think this may be a good time to discuss how we want to support Qt for
> WebAssembly and what direction the project should take. I’ll start out
> by describing some recent developments:
>
> * We are targeting WebAssembly using Emscripten as the SDK. The platform plugin
> is implemented (mainly) using the html5.h API from emscripten.
>
> The platform define is Q_OS_HTML5. We have wip branches for qtbase and
> qtdeclarative. If (minor) adjustments are needed in other modules then
> those could be submitted to the 5.11 branch under the Q_OS_HTML5 define.
>
> * Binary sizes: We are using static builds. The minimal Qt demos (QtCore + QtGui) come
> out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + QtQuick + QtCharts)
> (as seen on Embedded World) is 6.3M.
>
> In the end it may be that application assets will contribute significantly to
> the overall application size. We can look into building an asset download
> pipeline using web service workers.
>
> * Load times: In addition to the network connection this depends on the browser
> wasm implementation, Firefox has recently gotten very fast and can download and
> instantiate the small Qt demos in a couple of seconds.
>
> * Qt Applications as web page components
>
> Qt for WebAssembly draws to a HTML <canvas> element. The default Qt html template
> makes the canvas cover the entire browser viewport, but any layout is possible.
> The size and position of the canvas may very well be outside of the applications
> control. Multiple canvases per “process” is possible but not yet supported.
>
> On the Qt side each canvas corresponds to a QScreen. The application is responsible
> for positioning windows on the screen(s). Qt::WindowFullScreen windows fill the entire
> canvas area with application content, normal windows get window decorations.
>
> We provide a Javascript API (qtloader.js) for managing the application process.
> (Here we have the luxury of using modern JS features due to the natural selection
> of browsers that the wasm requirement provides.)
>
> * Fonts
>
> We don’t have access to system font files. This means fonts must me embedded in
> the application binary or downloaded on demand.
>
> Exact font style matches with “native” system fonts will probably remain out of
> scope, but should still be able to match the font size setting. Page zoom is
> handled via the high-dpi implementation.
>
> * (No) thread support
>
> Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer,
> which has been disabled in all major browser after recent security incidents.
>
> So we are looking to upstream a no-thread configure option, and modules that
> want to work on the web should support it. It’s still possible to develop with
> pthreads enabled by enabling SharedArrayBuffer for your browser.
>
> No-thread could be implemented either by removing QThread (and friends), or by
> making QThread::start() a no-op.
>
> * QML interpretation vs compilation
>
> We’re currently using the QML interpreter, which is working reasonably well
> for development purposes. The end state is to compile to wasm, ahead of time.
>
> There has been some discussion on whether compilation should be implemented
> before anything is merged to the main Qt branches, or be handled later on.
>
> * Networking
>
> We are looking there approaches: (not mutually exclusive)
>
> - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch.
>
> This allows making HTTP REST requests back to the origin server, or to other servers
> by using CORS.
>
> - A QWebSocket (client) backend implemented using HTML5 WebSocket
>
> This would allow making websocket connections to any server.
>
> - Using the emscripten sockets implementation and websockify.
>
> This is a tunneling solution where the server runs e.g. websockify and will forward
> to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work
> is needed in Qt.
>
> * QtMultimedia
>
> Very open for contributions :)
>
> Further information including getting started instructions is available on QTBUG-63917,
> and also or on QTBUG-65198 (platform documentation).
>
> Thanks for reading!
> Morten
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Morten Sørvig
2018-03-12 10:58:09 UTC
Permalink
> On 9 Mar 2018, at 15:53, Jason H <***@gmx.com> wrote:
>
>
> I don't want to steal your thunder, but what is fundamentally different about this approach this time? Why will the results be any different?


Oh, who knows what will happen. But there are indicators that this time
may be different:

* WebAssembly is a web standard
* General support for web applications is getting better (e.g. service workers)
* Canvas-rendering web apps now exist (Google Sheets)
* Better connectivity makes “large” web apps more feasible.

The project _may_ end up providing limited value to Qt users, but I think
it would be a mistake to conclude so up front,

Morten
Jason H
2018-03-12 13:42:51 UTC
Permalink
> Oh, who knows what will happen. But there are indicators that this time
> may be different:
>
> 1. WebAssembly is a web standard
> 2. General support for web applications is getting better (e.g. service workers)
> 3. Canvas-rendering web apps now exist (Google Sheets)
> 4. Better connectivity makes “large” web apps more feasible.
>
> 5. The project _may_ end up providing limited value to Qt users, but I think
> it would be a mistake to conclude so up front,

I have taken the liberty of changing your bulleted list to an ordered one.

1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims.

2. I have no comment

3. Such apps are designed from ground-up for canvas. I don't know that a Qt app will scale accordingly. I tried WebGL for my app and it simply did not work. Maybe there are large gains, but he approaches are in the same vein.

4. a. While true, it hasn't been exponentially true like with most things in computing ( in terms of average speed https://www.pcmag.com/Fastest-Mobile-Networks ) Maybe with 5G that will change. Additionally, unless you can very slickly progressively load it, no one wants a 5-second delay or even 3 second delay. It's also rather biased to first-world countries and metropolitain customers. I doubt that's who Nokia had in mind for their "next billion". (The point being while now not technically limited by spec, you're still limited in practice)
b. Another point here is that the mobile web is taking off with less powerful ARM processors...
c. on Data plans that meter data...

5. Given the effort required it may be considered "low-hanging fruit" and provide value in the interim. However the maximally utilitarian solution is to stop cramming binaries into browsers, and run apps that properly utilize the browser no matter how twisted standards it uses.

Given the limitations outlined above, and considering the ecosystem implications, I am left to conclude that Qt needs to include a proper web component.
Lorn Potter
2018-03-12 19:38:40 UTC
Permalink
On 03/12/2018 11:42 PM, Jason H wrote:
> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims.

In my experience WebAssembly is much more performant than asmjs, wasm
also creates binaries that are at least 10x less huge than asmjs.

> Given the limitations outlined above, and considering the ecosystem
>implications, I am left to conclude that Qt needs to include a proper
>web component.

as they say... patches welcome :)
Jason H
2018-03-13 01:15:35 UTC
Permalink
> On 03/12/2018 11:42 PM, Jason H wrote:
> > 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims.
>
> In my experience WebAssembly is much more performant than asmjs, wasm
> also creates binaries that are at least 10x less huge than asmjs.

Active Qt was about 12mb IIRC for Tetris or samegame we're not we're still looking at the same sizes.

> > Given the limitations outlined above, and considering the ecosystem
> >implications, I am left to conclude that Qt needs to include a proper
> >web component.
>
> as they say... patches welcome :)

Sure. But how much refactoring is Qt going to accept without a commitment to the web agenda? How much prioritization will it be allowed? Will the Qt company support it as a real part of Qt? It's easy to say patches welcome, when there are none, but when there's a deluge will that love still be there?

What if I got the QmlWeb people to bring it into Qt, how soon can we release it with fanfare and call Qt a web development platform?
Tuukka Turunen
2018-03-13 06:39:36 UTC
Permalink
On 13/03/2018, 3.15, "Development on behalf of Jason H" <development-bounces+tuukka.turunen=***@qt-project.org on behalf of ***@gmx.com> wrote:
>
> Sure. But how much refactoring is Qt going to accept without a commitment to the web agenda? How much prioritization will it be allowed? Will the Qt company
> support it as a real part of Qt? It's easy to say patches welcome, when there are none, but when there's a deluge will that love still be there?

Currently this is still research, as I explained in my recent roadmap blog post. But there certainly is a lot of business interest towards this, and we are making good progress technically. Even rather complex and dynamic UIs work decently on a desktop machine. At least with Chrome, unfortunately not all browsers are yet on par with it when it comes to WebAssembly. Assumption is that this improves.

Yours,

Tuukka
Morten Sørvig
2018-03-13 09:21:35 UTC
Permalink
> On 13 Mar 2018, at 02:15, Jason H <***@gmx.com> wrote:
>
>> On 03/12/2018 11:42 PM, Jason H wrote:
>>> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims.
>>
>> In my experience WebAssembly is much more performant than asmjs, wasm
>> also creates binaries that are at least 10x less huge than asmjs.
>
> Active Qt was about 12mb IIRC for Tetris or samegame we're not we're still looking at the same sizes.

The download size for the current build of samegamne.wasm is 4.4mb. (compressed with brotli)

Morten
Svenn-Arne Dragly
2018-03-13 14:27:33 UTC
Permalink
On 03/09/2018 03:53 PM, Jason H wrote:
> While I am excited about this, I still wonder that it's the right approach. By right, I mean scalable.
> After evaluating the WebGL platform (which I was excited about as well) had having extreme performance issues, I foresee that this will has performance issues as well, because of one defect: You're rendering to a canvas what the browser can draw natively. If people want to serve Qt apps to the web, then the best approach (IMHO) is to use a server to send a client which is defined in HTML5 (name clash with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a QPainter). This will leverage the browser in the best way possible, and let it handle the low-level drawing. To this end QMLWeb is an existing approach (https://github.com/qmlweb/qmlweb).
I think this depends on the use case. QMLWeb is doing a great job of
bringing the QML language to web applications, which I personally find
much more appealing than working with HTML and CSS. And it is probably
best to leverage the browser to draw efficiently in cases where using
DOM elements makes sense. This is likely the case for social media
applications, news readers, ticket services, database browsers, etc.

However, for use cases where a canvas already is the main element,
either for 2D or 3D content, I think Qt for WebAssembly makes a lot of
sense. The difference then is just what language and framework you use
to produce the code that ends up drawing the canvas. And you will still
have plenty of UI elements available with buttons, sliders, and
checkboxes for your menus. This could be a good fit for image editing,
painting, 3D modeling, data visualization, games, simulators, etc.

I also think Qt for WebAssembly is exciting because it opens up the
possibility to show a minimal demo of a full application in the browser.
Instead of showing a video of the application on a product page, a small
demo with limited features can be presented. Sure, it might not be as
fast and doesn't have the same features as the full application (after
all, you want to keep the download size to a minimum for the demo), but
it will give the user a much better idea of what your application really
is like. And the best part is that you can create the demo from the same
code base as you used in the full application.

Svenn-Arne
Morten Sørvig
2018-03-14 09:32:46 UTC
Permalink
> On 13 Mar 2018, at 15:27, Svenn-Arne Dragly <svenn-***@qt.io> wrote:
>
> I also think Qt for WebAssembly is exciting because it opens up the possibility to show a minimal demo of a full application in the browser. Instead of showing a video of the application on a product page, a small demo with limited features can be presented. Sure, it might not be as fast and doesn't have the same features as the full application (after all, you want to keep the download size to a minimum for the demo), but it will give the user a much better idea of what your application really is like. And the best part is that you can create the demo from the same code base as you used in the full application.

I also see this demo use case as a realistic short/medium term goal, where we can provide value for current Qt users.

Morten
Tim Murison
2018-03-09 18:09:01 UTC
Permalink
> <box type="soap">
> While I am excited about this, I still wonder that it's the right
> approach. By right, I mean scalable.
> After evaluating the WebGL platform (which I was excited about as
> well) had having extreme performance issues, I foresee that this will
> has performance issues as well, because of one defect: You're
> rendering to a canvas what the browser can draw natively. If people
> want to serve Qt apps to the web, then the best approach (IMHO) is to
> use a server to send a client which is defined in HTML5 (name clash
> with Q_OS_HTML5) as non-canvas DOM elements (unless you're using a
> QPainter). This will leverage the browser in the best way possible,
> and let it handle the low-level drawing. To this end QMLWeb is an
> existing approach (https://github.com/qmlweb/qmlweb).
>
> While I wish you the best of luck, I don't think it's going to work
> out well. The other day I asked the question on the blog, "Why can't
> we divorce behavior from the the UI?" (conceptually speaking) I was
> asking it in the context of QtQuick/QWidgets consistency, but I'd
> like to extend that to HTML elements as well. You should be able to
> define the UI component and the behavior component of a GUI item
> seperately and just attach the same behaviors to he various UIs. The
> thing here is that the HTML version of it would already come with
> some behaviors supplied by the browser, and the UI component would
> similarly be rendered by the browser. I know this isn't do-able in 5,
> or maybe even 6, but it's where I think things are headed.
>
> For example, a simple .ui file translator that gives you a HTML5 app
> would be the start. If you don't think this is possible, you should
> check out Webtoolkit (https://www.webtoolkit.eu/wt) which is a copy
> of Qt for the web. It works. At one point I wrote a script t
> translate Designer's .ui files from the Q* to the W* versions and it
> worked, mostly. If Qt wants to target the web, properly then bringing
> in Wt would be the 'proper' (IMHO) approach.
>
> We've had efforts to cram Qt binaries into browsers for over 10 years
> now (ActiveQt). None of it has really succeeded. I speculate it's
> because the initial load time is a huge turn-off. You can't use Qt
> for regular web sites, soo the appeal is limited. The ideal approach
> is one where Qt is advanced as a preferred web development
> technology, as well as a native technology. Incidentally that also
> opens Qt up to the biggest possible licensing base.
> Qt can compete with (and IMHO is better than) React and Angular. But
> this smallest-effort-to-the-browser is fundamentally broken, and I
> think will only result in an "also-ran" situation.
>
> I don't want to steal your thunder, but what is fundamentally
> different about this approach this time? Why will the results be any
> different?
> </box>

+1, I couldn't agree more with this sentiment.

I work in software consulting doing mobile and web work. While Qt has a
compelling offering in the mobile and desktop space with Qml, web work
has to be done with another toolkit. These days, react-native or
Angular are derigeur. As a result it is not possible to effectively
evangelize for Qt until Qt can match these technologies. Qt needs a web
solution that is as well adapted to the platform and as flexible as the
existing Qt solutions for mobile and desktop are. As described this 'Qt
for WebAssembly' feature seems to result in web applications that would
not be acceptable in many use cases.

I'd also like to echo and hopefully amplify what Jason H said about
qmlweb. IMO, this is the solution that Qt should be embracing and
integrating upstream. qmlweb aims to do what Qt has always done, make
cross-platform development easy, efficient and indistinguishable from
native development.
Jason H
2018-03-09 19:45:54 UTC
Permalink
> Sent: Friday, March 09, 2018 at 1:09 PM
> From: "Tim Murison" <***@gmail.com>
> To: ***@qt-project.org
> Subject: Re: [Development] Qt for WebAssembly
>
> > <box type="soap">
...
> > </box>
>
> +1, I couldn't agree more with this sentiment.
>
> I work in software consulting doing mobile and web work. While Qt has a
> compelling offering in the mobile and desktop space with Qml, web work
> has to be done with another toolkit. These days, react-native or
> Angular are derigeur. As a result it is not possible to effectively
> evangelize for Qt until Qt can match these technologies. Qt needs a web
> solution that is as well adapted to the platform and as flexible as the
> existing Qt solutions for mobile and desktop are. As described this 'Qt
> for WebAssembly' feature seems to result in web applications that would
> not be acceptable in many use cases.
>
> I'd also like to echo and hopefully amplify what Jason H said about
> qmlweb. IMO, this is the solution that Qt should be embracing and
> integrating upstream. qmlweb aims to do what Qt has always done, make
> cross-platform development easy, efficient and indistinguishable from
> native development.

Thanks Tim, I'm glad to know I'm not the only one. I *highly* recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even if it's not LGPL. The Widget gallery is implemented in Wt, and you can see they have everything, and even a working TreeView! Your QWidget experience will transfer directly, but you'll have to get used to using Boost. And it's fast. I "feels" faster than any other website.

If it were me (and wishes were fishes, we'd all eat for free) I'd take on QMLWeb even as a loss-leader. Even though it's not able to be commercialized, having an API that applies across paradigms strengthens the position of Qt. You'll learn it for one paradigm, then be able to carry it into another. Given that there are far more web developers, it' more likely that you'll extend them into a licenseable Qt territory, rather than Qt licensers move out of licensable territory. It's the same thing that Qt has already done - make desktop developers able to target Raspberry Pi Zeros, except on a much, much larger scale.

And at the end of the day, whenever I use a web technology I'm grumbling because I'm not using Qt. Qt is a far superior solution. But if it doesn't open itself to a wider audience it'll continue to be obscure (But still used by major companies). But my point is when I say "Qt" people ask what's that? Or they ask "you mean que tee"? (indicating a branding problem)
Tim Murison
2018-03-09 20:05:52 UTC
Permalink
> Thanks Tim, I'm glad to know I'm not the only one. I *highly*
> recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even
> if it's not LGPL. The Widget gallery is implemented in Wt, and you
> can see they have everything, and even a working TreeView! Your
> QWidget experience will transfer directly, but you'll have to get
> used to using Boost. And it's fast. I "feels" faster than any other
> website.

I looked into Wt briefly a few months ago, but for my kind of work, Qml
is a much better fit than widgets, hence qmlweb would be ideal if it
were integrated into Qt. In fact I'd go as far as saying that not
having a qmlweb type of solution has been the primary reason I haven't
been able to use Qt in at least 3 commercial products, so anecdotally
it is a direct cause of revenue loss for TQtC.

> And at the end of the day, whenever I use a web technology I'm
> grumbling because I'm not using Qt. Qt is a far superior solution.
> But if it doesn't open itself to a wider audience it'll continue to
> be obscure (But still used by major companies). But my point is when
> I say "Qt" people ask what's that? Or they ask "you mean que tee"?
> (indicating a branding problem)

I agree with this also. For what it's worth, developer surveys tend to
include all sorts of flavour-of-the-week web/mobile toolkits in their
lists, and they never have Qt.
Jason H
2018-03-09 21:28:32 UTC
Permalink
> Sent: Friday, March 09, 2018 at 3:05 PM
> From: "Tim Murison" <***@gmail.com>
> To: ***@qt-project.org
> Subject: Re: [Development] Qt for WebAssembly
>
>
> > Thanks Tim, I'm glad to know I'm not the only one. I *highly*
> > recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even
> > if it's not LGPL. The Widget gallery is implemented in Wt, and you
> > can see they have everything, and even a working TreeView! Your
> > QWidget experience will transfer directly, but you'll have to get
> > used to using Boost. And it's fast. I "feels" faster than any other
> > website.
>
> I looked into Wt briefly a few months ago, but for my kind of work, Qml
> is a much better fit than widgets, hence qmlweb would be ideal if it
> were integrated into Qt. In fact I'd go as far as saying that not
> having a qmlweb type of solution has been the primary reason I haven't
> been able to use Qt in at least 3 commercial products, so anecdotally
> it is a direct cause of revenue loss for TQtC.

QML is just amazing rockstar tech, approaching ideals.

> > And at the end of the day, whenever I use a web technology I'm
> > grumbling because I'm not using Qt. Qt is a far superior solution.
> > But if it doesn't open itself to a wider audience it'll continue to
> > be obscure (But still used by major companies). But my point is when
> > I say "Qt" people ask what's that? Or they ask "you mean que tee"?
> > (indicating a branding problem)
>
> I agree with this also. For what it's worth, developer surveys tend to
> include all sorts of flavour-of-the-week web/mobile toolkits in their
> lists, and they never have Qt.

The RoW (rest of world) has no problem taking their web apps, and wrapping them in WebKit and making an app out of it. (Case, Point: Googles new Chat app is an Electron app) The web is trespassing into the space of applications. It's time the applications trespassed on the web.
Morten Sørvig
2018-03-12 11:29:08 UTC
Permalink
> On 9 Mar 2018, at 19:09, Tim Murison <***@gmail.com> wrote:
> I'd also like to echo and hopefully amplify what Jason H said about
> qmlweb. IMO, this is the solution that Qt should be embracing and
> integrating upstream. qmlweb aims to do what Qt has always done, make
> cross-platform development easy, efficient and indistinguishable from
> native development.


I think qmlweb and Qt for wasm are fundamentally different enough
(reimplementing Qt Quick vs recompiling it for a new platform) that they
are not mutually exclusive. We could accept either or both upstream,

It could be interesting to make them API-compatible so that users can
move between them with minimal effort. For example by providing a “QtQuick.QMLEngine()”
Javascript API that can be used interchangeably with “QmlWeb.QMLEngine()”.

var div = document.getElementById('embed');
var engine = new QmlWeb.QMLEngine(div);
engine.loadFile('qml/main.qml');
engine.start();

Morten
Jason H
2018-03-12 13:43:42 UTC
Permalink
> Sent: Monday, March 12, 2018 at 7:29 AM
> From: "Morten Sørvig" <***@qt.io>
> To: "Qt Project Development Mailing-List" <***@qt-project.org>
> Subject: Re: [Development] Qt for WebAssembly
>
>
>
> > On 9 Mar 2018, at 19:09, Tim Murison <***@gmail.com> wrote:
> > I'd also like to echo and hopefully amplify what Jason H said about
> > qmlweb. IMO, this is the solution that Qt should be embracing and
> > integrating upstream. qmlweb aims to do what Qt has always done, make
> > cross-platform development easy, efficient and indistinguishable from
> > native development.
>
>
> I think qmlweb and Qt for wasm are fundamentally different enough
> (reimplementing Qt Quick vs recompiling it for a new platform) that they
> are not mutually exclusive. We could accept either or both upstream,
>
> It could be interesting to make them API-compatible so that users can
> move between them with minimal effort. For example by providing a “QtQuick.QMLEngine()”
> Javascript API that can be used interchangeably with “QmlWeb.QMLEngine()”.
>
> var div = document.getElementById('embed');
> var engine = new QmlWeb.QMLEngine(div);
> engine.loadFile('qml/main.qml');
> engine.start();

Yes, exactly.
Lorn Potter
2018-03-09 19:16:55 UTC
Permalink
Hi, I would like to add...
One of the guys over at https://qtmob.slack.com keeps a demonstration of
the Qt examples for Qt Webassembly (thanks David!):

https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html

Not all of the examples work, and not all of them work correctly.
Firefox seems to be fastest.

On 9/3/18 10:57 pm, Morten Sørvig wrote:
> Hi all,

> * Networking
>
> We are looking there approaches: (not mutually exclusive)
>
> - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch.
>
> This allows making HTTP REST requests back to the origin server, or to other servers
> by using CORS.
>
> - A QWebSocket (client) backend implemented using HTML5 WebSocket
>
> This would allow making websocket connections to any server.
>
> - Using the emscripten sockets implementation and websockify.
>
> This is a tunneling solution where the server runs e.g. websockify and will forward
> to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work
> is needed in Qt.

While emscripten translates native sockets into websockets, the issue
with just using sockets for networking like Qt internally does, is that
there are no real DNS lookups due to the sandbox in which webassembly
runs. Which is why we needed to use alternate methods.

There are also emscripten's wget functions. At least to download,
emscripten has various _wget* functions which are available.


Probably the biggest gotcha, is that exec currently does not return in
the way you would expect. So for example, the scribble example does not
change the pen color.
Morten Sørvig
2018-03-14 09:54:16 UTC
Permalink
> On 9 Mar 2018, at 13:57, Morten Sørvig <***@qt.io> wrote:
>
> * (No) thread support
>
> Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer,
> which has been disabled in all major browser after recent security incidents.
>
> So we are looking to upstream a no-thread configure option, and modules that
> want to work on the web should support it. It’s still possible to develop with
> pthreads enabled by enabling SharedArrayBuffer for your browser.


It was pointed out to me that we already have pending patches in this area:

https://codereview.qt-project.org/181112
https://codereview.qt-project.org/180973
https://codereview.qt-project.org/180971
https://codereview.qt-project.org/180972
https://codereview.qt-project.org/177459

I suggest we restore and merge those since we now have an additional use
case in the form of a platform requirement.

(The alternative would be to wait it out - perhaps threading support will be
enabled and stable in all browsers before we get to merge wip/webassembly).

Morten
Lorn Potter
2018-03-14 23:09:55 UTC
Permalink
On 03/14/2018 07:54 PM, Morten Sørvig wrote:
>
>> On 9 Mar 2018, at 13:57, Morten Sørvig <***@qt.io> wrote:
>>
>> * (No) thread support
>>
>> Wasm and Emscripten do have pthreads support. However this requires SharedArrayBuffer,
>> which has been disabled in all major browser after recent security incidents.
>>
>> So we are looking to upstream a no-thread configure option, and modules that
>> want to work on the web should support it. It’s still possible to develop with
>> pthreads enabled by enabling SharedArrayBuffer for your browser.
>
>
> It was pointed out to me that we already have pending patches in this area:
>
> https://codereview.qt-project.org/181112
not sure why anyone would want to stop/block execution of the one and
only thread.

> https://codereview.qt-project.org/180973
> https://codereview.qt-project.org/180971
> https://codereview.qt-project.org/180972
^ these we already have :)


> https://codereview.qt-project.org/177459
Certainly our thread feature needs to be fixed for non wasm builds.

>
> I suggest we restore and merge those since we now have an additional use
> case in the form of a platform requirement.
>
> (The alternative would be to wait it out - perhaps threading support will be
> enabled and stable in all browsers before we get to merge wip/webassembly).

I keep watching out for this in wasm/emscripten. It's been a 'soon'
feature for a while.
Ulf Hermann
2018-03-15 07:22:08 UTC
Permalink
>> https://codereview.qt-project.org/181112
> not sure why anyone would want to stop/block execution of the one and
> only thread.

sleep() and friends do have a place in single threaded applications. You can use them to do some backoff mechanism when waiting for an external event. You shouldn't do that when user interaction is allowed, but there is no reason not to have them in the API. Furthermore, not having them makes things more complicated as we are using them ourselves and some code would have to be wrapped in #ifdef to compile without them. Btw, if you look at the patch, you'll notice it doesn't actually add or remove any code. It only moves #ifdefs around.

>> https://codereview.qt-project.org/180973
>> https://codereview.qt-project.org/180971
>> https://codereview.qt-project.org/180972
> ^ these we already have :)

... I guess I have to try "configure -no-feature-thread" again and see what happens.

Ulf
Viktor Engelmann
2018-03-15 09:57:56 UTC
Permalink
I am personally quite excited about having a common standard for
binaries on the web, that can be generated from C++ and I think there is
a lot of potential and I am happy to see Qt going in that direction.

Regarding the load-times: WebAssembly supports dynamic linking, so
browsers might cache Qt libraries, so they would only have to download
them once. If the pages loaded the libs from a common location (say
download.qt.io), they would even only have to load them once for all
pages that use them. (I do have to say that I've had bad experiences
with the caching of wasm files - sometimes they aren't even reloaded
after new versions are on the server... but that should only be a
temporary problem).

About the threading: there are Web Workers in the HTML5 standard. These
basically are threads, but they are harder to use (for example because
of /*strict*/ ownership of objects), so it might not be feasible to map
threads to Web Workers... Just throwing it into the discussion.

--

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
***@qt.io
+49 151 26784521
http://qt.io

GeschÀftsfÌhrer: Mika PÀlsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com
Edward Welbourne
2018-03-15 10:22:06 UTC
Permalink
Morten Sørvig (14 March 2018 10:54)
> (The alternative would be to wait it out - perhaps threading support will be
> enabled and stable in all browsers before we get to merge wip/webassembly).

From recent discussion with a Firefox developer, I gather that browser
vendors are generally trying to restore SharedArrayBuffer in wasm, at
least; which is likely to result in it also being restored to JS.

However, mitigating the Spectre weakness may involve constraining the
use of SharedArrayBuffer; details remain unclear (and shall probably
require developers from different browsers to reach a consensus on
what's a good way to do this).

He also noted that SharedArrayBuffer is a run-time preference in Firefox
(about:config -> javascript.options.shared_memory); but it's a global
option, not per-site, so enabling it may make expose you to Spectre
exploits.

Eddy.
Continue reading on narkive:
Loading...