Right, the library doesn't seem to be very Windows friendly. It assumes the pointers to GL functions resolved and available in global scope, which is not how it usually works on this platform. Moreover it seems to force ANGLE and OpenGL ES (or at least tries to) on Windows in the .pri file, but then is inconsistent in how it checks for that.
I'd say contact the authors and ask them to fix the Windows parts.
Sorry for the slow reply. Thanks both for your responses! I've had a quick look at GLSL #include before — I'm not exactly sure how to use it (this is a start though) — but apart from that, I'd prefer a way to do this in Qt, possibly more customizable and also driver-independent (e.g. I'm not sure if all graphics drivers support this GLSL extension). In addition to that, it would be a good feature to share with my students who might use Qt also for later/future projects.
I'm developing the software in an academic setting — when the (to be included) GLSL files have changed, things need to be (pre)processed again. Basically I wondered whether it's possible to automatically check .glsl files with a preprocessor for some tag (#pragma seems a good choice) and act on it, in this case use some sed/regex line to replace the mentioned file by the contents of that file. This could happen before every Build, or even before every Run (depending on how straightforward it is to save the copy-pasted version after Building and re-use it when Running, or just do this before every Run).
Any thoughts about experience with integration OpenGL with QtQuick/Widgets are welcome. Maybe I'll have to check it myself how it behaves. I've read some materials about it (mostly from KDAB) but they usually aim simple case where synced data is really small eg. camera info + a few additional bytes of data.
@Devopia53 I tested on Qt 5.8/Win7 today. The same incorrect result. But today i discovered the difference in overlaping behavior on my two machines. On the machine with video card fully-transparent widget has black color on white opengl context :D, where as other machine with integrated video card has no color(as should). So the gui transparency on opengl context is very platform dependent. Solution is to render widget by opengl directly but this way is very inconvenient. I think troll-tech must solve this problem in future.
Assuming you have an OpenGL context and you can draw/create objects in it you would make that context current, then create a QOpenGLPaintDevice and use it to render() the widget into that. Please note that a widgets require a QApplication instance and a running Qt's event loop, so you would need to ensure you have that.
As for DirectX Qt doesn't have any direct support for it, but you could probably grab() a widget into a QPixmap, transfer the pixels to a DirectX texture and draw a quad with it.
If you feel adventurous you could also implement your own QPaintEngine, then subclass QPaintDevice to return that engine and use it like with the OpenGL version.
I just don't know what the purpose of setting it is.
Me neither, sorry. The only thing that I gather from the docs is that all Canvas3D objects have name parameter, much like QObject/ QML QtObject, so perhaps it can be used to search objects by name. It's only a guess, though.