openscad / openscad

OpenSCAD - The Programmers Solid 3D CAD Modeller
https://www.openscad.org
Other
7.03k stars 1.21k forks source link

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

Closed zwieblum closed 4 years ago

zwieblum commented 4 years ago

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 commented 4 years ago

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

zwieblum commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

It's arm7l.

Where do I place that CONFIG += qopenglwidget ?

t-paul commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

t-paul commented 4 years ago

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 commented 4 years ago

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

spillner commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.