qt-web-view-widget VS smallfunction

It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite.

My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for.

Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better.

The solution to most things in QML is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your QML widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a QML widget class because you just can't simply do that.

For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a QML widget only, rather that do the obvious thing of exposing it as a C++ class and providing a QML widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods.

But I realized that, at that point, there was no longer any point in using QML if I was going to have to use some neat tricks in C++.

So in just a day, I wrote a classic widget that implements the same WebView used in the QML version, just without any of the QML crap.

https://github.com/Ravenstine/qt-web-view-widget

And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill.

Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part.

I wish they'd abandon QML and just focus on making the experience of writing completely native apps better.

However, std::function which can be used for storing multiple closures can indeed heap allocated. Since this is undesirable, I use an equivalent with static fixed storage instead: https://github.com/jcelerier/smallfunction/blob/master/smallfun/include/smallfun.hpp which gives me a compile error if I try to stuff too much data in there.

and conversely from the engine to the UI thread ; Qt signals do not cut it as emitting them allocate, if only a few bytes. (Doing it naively with std::function doesn't cut it either - I use this instead to store these functions: https://github.com/jcelerier/smallfunction/blob/master/small... ; also, the audio threads feeds back those functions into the main thread after their execution so that any memory owned by the lambda ends up being freed here and not in the audio thread.)