* It's easier to find people with JS skills than C++ skills
* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.
* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).
* Remote connections are trivial. People only need a browser to connect remotely.
The people at the company who have been using it like it a lot. They just have to put together a few tags and boom there's your GUI.
The GUI has access to some system variables via WebSocket. We have a two-way binding abstraction so people don't have to think too much about events and such.
I wouldn't recommend HTML for a small company though. Better stick to Qt if you're a small group of competent C++ programmers.
Is most of your gui simple forms and data? I've done critical care monitors and photobooths, and both seem too complex for html to me. I'd be afraid the HTML would be too slow to process and display, too eager to show scrollbars, too likely not to be optimized for the embedded gpu, etc. Have any experience there? The last time I tried going higher level I tried embedded flash, and that was too limiting.
Just for the record I'd never do an embedded gui in html. Well maybe not never, but not until it's common. Sounds like a nightmare of layers and compatibility issues. If you run into a problem, where do you even start to look?
I've been doing straight opengl-es on my devices and like not being locked into a gui platform. It makes even more sense to do it this way when you've got external buttons as inputs, because you're not even able to use slots and signals, which is the most useful part of qt.
On an embedded device you're gonna be shipping the runtime environment (aka the browser) also. So the typical challenges of compatibility with HTML5/JS of many moving target platforms doesn't really exist.
Comments
Why are you moving away from Qt?
A few reasons:
* It's easier to find people with JS skills than C++ skills
* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.
* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).
* Remote connections are trivial. People only need a browser to connect remotely.
The people at the company who have been using it like it a lot. They just have to put together a few tags and boom there's your GUI.
The GUI has access to some system variables via WebSocket. We have a two-way binding abstraction so people don't have to think too much about events and such.
I wouldn't recommend HTML for a small company though. Better stick to Qt if you're a small group of competent C++ programmers.
Is most of your gui simple forms and data? I've done critical care monitors and photobooths, and both seem too complex for html to me. I'd be afraid the HTML would be too slow to process and display, too eager to show scrollbars, too likely not to be optimized for the embedded gpu, etc. Have any experience there? The last time I tried going higher level I tried embedded flash, and that was too limiting.
Just for the record I'd never do an embedded gui in html. Well maybe not never, but not until it's common. Sounds like a nightmare of layers and compatibility issues. If you run into a problem, where do you even start to look?
I've been doing straight opengl-es on my devices and like not being locked into a gui platform. It makes even more sense to do it this way when you've got external buttons as inputs, because you're not even able to use slots and signals, which is the most useful part of qt.
On an embedded device you're gonna be shipping the runtime environment (aka the browser) also. So the typical challenges of compatibility with HTML5/JS of many moving target platforms doesn't really exist.
Exactly.