On Thu, Jan 07, 2016 at 10:47:35PM +0100, Torsten Paul wrote: > It seems the best short term solution is to enable usage of the > new QOpenGLWidget "qmake CONFIG+=qopenglwidget". Unfortunately we > can't just enable it in general as this needs Qt5.4 and also is > causing issues on MacOSX and totally breaks on Windows. > > On Linux it seems to work, but did not get much testing yet.
debian stretch already has qt 5.5, so no issues there; for backports, qt4 is likely to be the way to go. using qopenglwidget does produce non-dragging qt5 binaries in debian for me, but only for openscad master, not for 2015.03-2. tracking the introduction of openglwidget, the option was added around 4af8cc75 and 001712e6. i've picked what looks like the relevant commits onto 2015.03-2, and obtained a non-dragging qt5 bulid that is stil largely a 2015.03-2. (i'd welcome a release that includes all that, but fully understand "it's ready when it's ready"). i'll target uploading to experimental since you describe qopenglwidget as rather untested -- thus, the new widget can get some more testing, and a package will still be available. apart from mouse interaction that has definitely improved with the new widget, are there particular pitfalls to observe or areas to test around? > Just now looking at the code, that line might have been disabled > by the patch that introduces QOpenGLWidget (but I'm not sure if > that's included in 2015.03-1). not even in -2; all the QOpenGLWidget changes were introduced later. > There's some work going on to update the legacy OpenGL code, but > with the limited dev resources that might take a while... slightly off topic, but does this mean that openscad is moving in the direction of gles? (don't feel pressured in that direction, just know that if it were, openscad could drop out of the line of fire between qt and opengl on arm at [1]). thanks chrysn [1] http://bugs.debian.org/798408
signature.asc
Description: PGP signature
