What I would like is something like electron that can run on a frame buffer. What's the current state of the art for a html5 based embedded interface?
I mean, if you don't need to modify the Qt-library, you don't need commercial license. You just need to provide link to the Qt-sources.
Which clause of the GPL/LGPL makes you say that, or is there prior judgement that resulted in making such a demand?
If you intend to launch a closed-source* product at some future date and pay the per-unit licensing fees, the developer needs a seat license from day one.
(* closed-source or code that statically links in the Qt libraries)
* Not accusing you of course; I'm totally convinced that it can come from a misguided sales rep trying to close a deal as early as possible.
Personally, I'm keeping my eye open on libui (https://github.com/andlabs/libui/) as it is already possible to do some basic things with it. However, it is pretty much in alpha state and I'm slowly writing the Python bindings for it at https://github.com/joaoventura/pylibui/. The thing that I like in the libui is that it is a thin wrapper around platform specific frameworks. Therefore, the library is very small (some 340 KB) and it's as native as the underlying platform calls are..
Regarding Electron, I am writing an application on it, but it is too god damn heavy in terms of memory, disk space and boot time, and web front-end development is absolute chaos these days. Although I'm currently writing my app on it, it is mostly an MVP as I want to make pylibui/libui usable enough to switch to a pure desktop cross-platform library asap..
Try Sciter HTML/CSS engine then (http://sciter.com). It is a monolitic DLL (4-8 Mb) without external dependencies. Works on Win/Lin/OSX and even on Raspberry Pi 2 - http://sciter.com/sciter-on-raspberry-pi-2/
How dare Qt demand that others pay them before developing a commercial product using their code?
I have no problem paying Qt. I'm just unwilling to do it until I know its the direction I want to go. The current Qt licensing structure adds friction to my making that decision.
Most commercial vendors won't give you their entire product for free until your own product is half-built. Qt is different; they offer an entire free product. You want to have your cake and eat it too.
Does the company that you work for (or yours if you're a founder) take the same "take it or leave it" attitude towards potential customers?
So does Qt. So much so in fact, they even offer an entire free product; evaluate it all you want. Just don't use it to build a commercial product while paying zero dollars and then come back when it's half-built and expect to dictate pricing terms after the fact.
> Does the company that you work for (or yours if you're a founder) take the same "take it or leave it" attitude towards potential customers?
I'm not going to talk about my work here. I'm writing on my anonymous behalf only. I've worked at places that were more or less liberal with evaluations and more or less tolerant of tiny accounts. I have never worked somewhere that salespeople loved customers who wasted their time asking for freebies and handouts with illusory promises of future money that never seems to materialize.
The incentives for me to comply with those terms are nonexistent, which is never a sign of a good contract.
It feels like the Qt Company is pushing C++ down the stack, with QML getting the main focus as application development language.
You don't want a Word-like app in your car dashboard, but a iOS-like app.
Same applies to Android, UWP and even Tizen with their respective native languages.
So it is a conscious decision not to provide C++ APIs besides the old QtWidget and make developers use QML and its compiler instead, as far as I understand it.
I've used Qt myself for desktop, mobile, and embedded development. For mobile and embedded I would not use widgets, and probably not even for desktop. I understand why the widgets still has staunch fanbase, but they do not belong everywhere.
