Qt Blog

Most C and C++ programmers' mental models of the machine is different to the abstract machine in the respective specifications. [1] There's a genuine problem here of overly clever optimizers wilfully misreading code to produce fast, wrong code. But the compiler exists to map our ideas into code; it's a tool to help us, not catch us out in a lawyerly fashion.

I will say that the article isn't a fantastic example, but at the same time it isn't too far off a more common idiom that is also UB as it is usually expressed - type punning. And type punning almost always works, except when it doesn't - http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/

[1] In particular, most programmers think pointers are simply numbers that represent memory addresses and that the chief distinguishing thing about null pointers is that accesses through them usually cause a memory page error owing to how the OS has mapped memory.

I've been developing a cross-platform file manager [1] for the past 2.5 years. It is shareware with a nag screen. It currently makes ~$500 per month. Generally, I would say yes, shareware still works. But it is hard a) to write desktop software [2] and b) to convince people to pay for it. I would not give people the sources. It would make them feel even more like "I don't need to pay for this". What works for me is to be very transparent and tell people [3] "I'm one guy working on this, and am making $500 per month. This is not sustainable. If you like the project and want it to continue, buy a license".

Feel free to hit me up on twitter @m_herrmann if you have further questions. :-)

1: https://fman.io

2: https://blog.qt.io/blog/2018/11/15/python-qt-3000-hours-developer-insight/

3: https://fman.io/buy

> Some time ago I published a couple of blog posts talking about Qt WebGL Streaming plugin

I had to search to find out for sure what he was talking about. A Qt application runs a small, local web server, streaming UI calls to a WebGL context on a page you view through your browser of choice. http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/

This differs from Electron in that your backend is C instead of JS, your UI is Qt instead of HTML, and the runtime doesn't embed the browser. I'm just guessing, but I suspect you also don't develop any code on the browser client context.

I've also personally found value in running Electron from a page in a local HTTP server process, so I don't find that part too different, but YMMV.

Maybe it's more appropriate to say this is like per-app RDP via WebGL.

Note that Qt has two separate technology previews for porting Qt apps to run in the web browser:

Qt WebGL streaming (qplatform/qpa plugin):

The Qt binary runs on your PC as normal, but instead of opening an X11/Win32 window, opens a network port. You can open the URL in a browser to see the interface. Only one connection is allowed / only one user can interact with the app at a time.

Technology preview since 5.10, will be "TP2" status in 5.11. See http://blog.qt.io/blog/2017/11/14/qt-webgl-cinematic-experience/ and http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/

Qt for WebAssembly:

The entire QtWidgets / QML libraries are compiled to WASM and run clientside. There is no server-side component.

Will be released as a technology preview in the upcoming 5.11 release.

Technically, LGPL option allows using in proprietary software. Practically, static linking is often better e.g. makes executable much smaller. And even with dynamic linking, see this note from https://blog.qt.io/blog/2009/11/30/qt-making-the-right-licensing-decision/

> If you are shipping an executable, you must include any data and utility programs needed for reproducing the executable (i.e. must provide components needed to recompile with a new version of the library) unless such data and utility programs are normally distributed with the major components of the operating system on which the executable runs

For developers of proprietary software, flutter’s BSD 3 clause license is way easier to comply.

Yes, I (post author) believe QML can be implemented on top of current browser tech, namely JS+DOM, or NaCl+WebGL. Someone indeed did implement a subset this way - https://qmlweb.github.io/ and the latter might even be supported by Qt Company - http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ although I didn't try that myself and I don't know if that effort is still ongoing.

I'm not a fan of stacking too many abstractions on top of each other. QML basically consists of the same ingredients as other web tech: a javascript runtime + GL/ES renderer + network access manager = same things a HTML5 engine needs under the hood. Surely these could be reused in a browser implementing QML.