error: ‘class QGLView’ has no member named ‘devicePixelRatio’

[zwieblum]

Current GIT version does not compile on RPi with Devuan Buster / Debian Beowulf. Error:

src/QGLView.h: In member function ‘virtual float QGLView::getDPI()’:
src/QGLView.h:45:41: error: ‘class QGLView’ has no member named ‘devicePixelRatio’
  float getDPI() override { return this->devicePixelRatio(); }

Replacing the said line with

 float getDPI() override { return 1.0; }

let's it build and run.

[t-paul]

Which version of Qt is used? What's the output of qmake?

[zwieblum]

QT: 5.11.3+dfsg1-1+deb10u4 qmake:

$ qmake openscad.pro 
Project MESSAGE: If you're building a development binary, consider adding CONFIG+=experimental
Project MESSAGE: Using QGLWidget
Project MESSAGE: Using C++14
Project MESSAGE: cairo enabled
Project MESSAGE: 3MF Import/Export enabled

[t-paul]

This is wrong:

Project MESSAGE: Using QGLWidget

On Linux systems with Qt5 it should select

Project MESSAGE: Using QOpenGLWidget 

I don't know why that would happen, that might be an issue with the Qt package. You can try forcing the selection via CONFIG += qopenglwidget.

[t-paul]

Hmm, actually it should have this function available regardless of the widget selection. So I don't know what's happening there.

Which platform is that? armv7l or aarch64?

[zwieblum]

It's arm7l.

Where do I place that CONFIG += qopenglwidget ?

[t-paul]

That is an option to qmake.

For arm7l Qt is usually compiled with GLES (not supported by OpenSCAD) instead of Desktop OpenGL. Does it actually show the 3D view with the code change from the original post?

[zwieblum]

Sorry, "compiles and runs" has just shown to be a bit unprecise. The code that runs is from 17. December 2018, commit 36bc309a7ae3036e5ea2de7932cc1dfd58a47aaa. It worked on Devuan Ascii without problems including 3D display. Somehow the QT5 development environment is not complete on RPi, but the old code still compiles and runs with qt4 :/

[t-paul]

Current OpenSCAD requires Qt5. It does work on aarch64 (e.g. the official beta Raspberry Pi OS 64-bit). I have no idea about Devuan.

For aarch64 there's also an AppImage on the snapshot download page.

[zwieblum]

I'm building a aarch64 image and will try again. Than you.

[t-paul]

Maybe check that there's both qt5 and qt5-gles packages are available. The default one should be Desktop OpenGL which works with OpenSCAD, the GLES one will either give compile errors or just not display any 3D stuff when running the application.

[t-paul]

Closing again as that does not seem to be an issue with OpenSCAD code...

[spillner]

I just hit the same issue, and I'm not sure I agree with "does not seem to be an issue with OpenSCAD code": the QGLView class is set up to derive from either QGLWidget or QOpenGLWidget, but its getDPI() member invokes a method offered only by QOpenGLWidget--- is there a good reason not to reimplement as

    float getDPI() override {

ifdef USE_QOPENGLWIDGET

            return this->devicePixelRatio();

else

            return 1.0f;

endif

    }

[t-paul]

Yes, it's not needed so far on any official builds. So before adding this, it needs to be clarified why this build is different. If that's building against a GLES version of Qt5, it will not work either way as that is not supported at all.

[spillner]

Yes, but "not supported" is not the same as "will not work." After a little more poking around I realized that the motivation for USE_QOPENGLWIDGET (and technical argument against such a simplistic change) is compatibility with older versions of Qt, but that's solvable with a slightly more sophisticated #ifdef. And honestly, the rendering backend seems fairly self-contained and looks like it could easily fit within the GLES footprint after minor modifications.

[t-paul]

GLES support would be great, but unless someone is taking on the topic, there's no point in increasing the maintenance burden. At this point the question is more if there's any use case for the old widget still. I think by now all builds use QOpenGLWidget, so support for the legacy widget could be completely removed.