Re: [Development] Qt for WebAssembly feature freeze exceptions

Hi, +1 to the emscripten upgrade. The upgrade is version 3.1.14 -> 3.1.27, which includes a number of fixes which are strongly desirable in 6.5. Cheers, David Skoland On 13 Dec 2022, at 11:14, Morten Sørvig via Development mailto:development@qt-project.org>> wrote: Hi all, We have two

[Development] Qt for WebAssembly feature freeze exceptions

Hi all, We have two pending changes for the wasm platform which I'd like to request a feature freeze exception for: * Adding the initial accessibility backend. This feature will initially be opt-in, and we are aiming to make it as non-disruptive as possible. A couple of

[Development] Qt for WebAssembly 5.13

Hi all, Qt for WebAssembly shipped as a tech preview for 5.12, and for 5,13 we want to fill in some of the missing pieces, and also make Q_OS_WASM a supported platform. Supported here does not mean that everything that does not work today will work, but rather that what we claim will work

Re: [Development] Qt for WebAssembly

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

Re: [Development] Qt for WebAssembly

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

Re: [Development] Qt for WebAssembly

>> 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

Re: [Development] Qt for WebAssembly

On 03/14/2018 07:54 PM, Morten Sørvig wrote: > >> On 9 Mar 2018, at 13:57, Morten Sørvig wrote: >> >> * (No) thread support >> >> Wasm and Emscripten do have pthreads support. However this requires >> SharedArrayBuffer, >> which has been disabled in all major browser

Re: [Development] Qt for WebAssembly

> On 9 Mar 2018, at 13:57, Morten Sørvig 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

Re: [Development] Qt for WebAssembly

> On 13 Mar 2018, at 15:27, Svenn-Arne Dragly 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,

Re: [Development] Qt for WebAssembly

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

Re: [Development] Qt for WebAssembly

> On 13 Mar 2018, at 02:15, Jason H 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

Re: [Development] Qt for WebAssembly

On 13/03/2018, 3.15, "Development on behalf of Jason H" wrote: > >Sure. But how much refactoring is Qt going to accept without a commitment > to the web agenda? How much prioritization will it be

Re: [Development] Qt for WebAssembly

> 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

Re: [Development] Qt for WebAssembly

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

Re: [Development] Qt for WebAssembly

> Sent: Monday, March 12, 2018 at 7:29 AM > From: "Morten Sørvig" <morten.sor...@qt.io> > To: "Qt Project Development Mailing-List" <development@qt-project.org> > Subject: Re: [Development] Qt for WebAssembly > > > > > On 9 Mar 2018, a

Re: [Development] Qt for WebAssembly

> 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

Re: [Development] Qt for WebAssembly

> On 9 Mar 2018, at 19:09, Tim Murison 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

Re: [Development] Qt for WebAssembly

> On 9 Mar 2018, at 15:53, Jason H 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

Re: [Development] Qt for WebAssembly

> Sent: Friday, March 09, 2018 at 3:05 PM > From: "Tim Murison" <tim.muri...@gmail.com> > To: development@qt-project.org > Subject: Re: [Development] Qt for WebAssembly > > > > Thanks Tim, I'm glad to know I'm not the only one. I *highly* > > recom

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

Re: [Development] Qt for WebAssembly

> Sent: Friday, March 09, 2018 at 1:09 PM > From: "Tim Murison" <tim.muri...@gmail.com> > To: development@qt-project.org > Subject: Re: [Development] Qt for WebAssembly > > > ... > > > > +1, I couldn't agree more with this sentiment. >

Re: [Development] Qt for WebAssembly

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

Re: [Development] Qt for WebAssembly

> > 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

Re: [Development] Qt for WebAssembly

damentally different about this approach this time? Why will the results be any different? > Sent: Friday, March 09, 2018 at 7:57 AM > From: "Morten Sørvig" <morten.sor...@qt.io> > To: "Qt Project Development Mailing-List" <development@qt-project.o

[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