Open Shinmera opened 7 years ago
Thanks to @sjl for bringing this up and helping with tracking down the cause as well as the potential workaround.
For completeness' sake, option 4: get CommonQt to support Qt5, then update qtools to use that. I feel like things are only going to bitrot more and more if one sticks with Qt4.
But that's probably a ton of work (and would break backwards compatibility), so option 3 seems sane to me.
The CommonQt update to Qt5 (and dropping Smoke in the process) is something I can't really feasibly do myself as I lack the experience and knowledge to do it. The only thing I can do regarding that is hope that @stassats will get enough motivation to work on it some more.
It turns out OS X actually only supports three OpenGL versions: 2.1, 3.2, and 4.1. The fix should also not be as recommended in the links above, but rather should happen in the QGLContextPrivate::tryFormat
method in qgl_mac.mm
. I've updated the file to test for the version or requested profile of the underlying QGLFormat and choose a "closest match". Not gonna be great, but it'll have to be good enough.
Haven't tested it yet because I'll need to compile it all and that'll take an OS X machine and some hours.
Alright, finally got around to compiling things and testing this. My code does seem to get executed and such, and a context is created that seems valid, but I don't think it's actually properly initialised. Querying GL for the minor/major version just returns garbage and the QGLFormat object seems to think there is no profile present and the GL version is 1.0. Something isn't working right.
@sjl What kind of tests were you performing before? I'm getting strange stray errors from GL all the time and I'm not sure if that's the fault of my Qt modifications or if it's just my setup being weird (testing in a VM).
I've attached the updated version of qtlibs!QtOpengl.dylib
. You should be able to just place it into qt-libs/standalone
. This is the test snippet I've run:
(ql:quickload '(cl-opengl verbose qtopengl))
(in-package :cl+qt)
(in-readtable :qtools)
(define-widget test (QGLWidget) ())
(defmethod construct ((test test))
(let ((format (q+:make-qglformat)))
;; (setf (q+:profile format) (q+:qglformat.core-profile))
(se
[qtopengl.zip](https://github.com/Shinmera/qtools/files/924335/qtopengl.zip)
tf (q+:version format) (values 4 5))
(new test format)
(let* ((context (q+:context test))
(format (q+:format context)))
(v:info :test "CONTEXT: ~a" (q+:is-valid context))
(v:info :test "QT: ~a.~a ~a" (q+:major-version format) (q+:minor-version format) (q+:profile format))
(v:info :test "GL: ~a.~a" (gl:get* :major-version) (gl:get* :minor-version)))))
(define-override (test initialize-g-l) ()
(gl:clear-color 0.1 0.15 0.2 1.0))
(define-override (test resize-g-l) (width height)
(gl:viewport 0 0 width height))
(define-override (test paint-g-l) ()
(gl:clear :color-buffer))
(defun cl-user::test ()
(with-main-window (w 'test)))
I'd appreciate it tremendously if you could try it on your own machine and let me know if it works for you.
Edit: forgot the damn file qtopengl.zip
Hey, I'm traveling til Sunday but will poke at it after that.
So what's the status, @sjl?
I'm crunching on the last couple weeks of my master's thesis and haven't had time to try this. Sorry :(
Where is the qt-libs/standalone
folder I need to put that file in? The current directory? Somewhere in the belly of quicklisp?
The qt-libs:*standalone-libs-dir*
variable will tell you
Oh, and- good luck on your thesis!
Aha, qt-libs-20170227-git/standalone
, explains why ffind didn't see it.
Well something changes. Before:
2017-05-15 20:26:50 [INFO ] <TEST>: CONTEXT: T
2017-05-15 20:26:50 [INFO ] <TEST>: QT: 1.0 #<ENUM QGLFormat::OpenGLContextProfile 0>
2017-05-15 20:26:50 [INFO ] <TEST>: GL: 0.0
After dropping in the file:
[SBCL] CL-USER> (test)
>> QT-LIBS
>> QT-LIBS
2017-05-15 20:29:19 [INFO ] <TEST>: CONTEXT: T
2017-05-15 20:29:19 [INFO ] <TEST>: QT: 1.0 #<ENUM QGLFormat::OpenGLContextProfile 2>
2017-05-15 20:29:19 [INFO ] <TEST>: GL: 2.2
Yeah, I'm still not sure whether it works as intended or not. The code changes that I've made are in accordance with all the information I've managed to dig up on the net.
Hi Shinmera, I'm designing an OpenGL application with qtools. What's the actual state concerning OSX compatibility? Thanks.
Still the same as in the OP.
Shouldn't this somehow be mentioned on the on the Qtools homepage ?
It's not exactly my fault Qt is broken.
Agree, users should be aware of this.
chuchana ha scritto:
Shouldn't this somehow be mentioned on the on the Qtools homepage ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Shinmera/qtools/issues/17#issuecomment-366673078, or mute the thread https://github.com/notifications/unsubscribe-auth/AWDNz7v0Q7hyXOR3HX_Fl-UtEew_Sxvqks5tWWR4gaJpZM4K3SWs.
I don't think the Qtools documentation should be come a bug tracker for Qt. It's simply not the right place.
Absolutely not, you have only big merits, but giving more visibility to this problem could cause someone to develop a workaround.
Nicolas Hafner ha scritto:
It's not exactly my fault Qt is broken.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Shinmera/qtools/issues/17#issuecomment-366673329, or mute the thread https://github.com/notifications/unsubscribe-auth/AWDNz9MBCraawiSWV8uJ2ckcAVul5Uugks5tWWSmgaJpZM4K3SWs.
I was absolutely not suggesting that it was your fault or even your responsibility. I just see this right now: Qtools is a cross platform GUI toolkit that does not work on a certain platform. Wherever that comes from, I'd rather know that from the start.
Qtools works just fine on OS X. The specific bug is Core GL contexts on OS X, which is only a Qt problem, not a Qtools problem. It is not appropriate to report problems about underlying libraries on this library's documentation.
Sorry for the misunderstanding: I thought this might be the reason why QTools didn't work for me on OS X. I'll see if I can find a solution for my problem and open another issue if I cannot.
Due to a bug in Qt 4, a QGLContext with a core context cannot be created. This makes it impossible to write modern OpenGL applications using Qt 4 and by extension Qtools.
There are reported workarounds for this however, notably overriding the
chooseMacVisual
method with one that performs modifications on theGDHandle
to initialise it properly. See Core3_2_context.h and core_profile_attributes.mm for an example on how to supposedly make it work for a 3.2 context.We have several ways to go about this from here on out:
If I can get Qt 4 built on OS X then I would find 3 to be the most favourable approach. It would implicitly fix applications and make them work "as expected" rather than requiring users to know and learn about the Qtools-UI extension.
The downside being that we will lock ourselves down with a custom Qt 4 version. However, given that Qt 4 is almost abandonware by now and no major changes nor fixes will be added to it, I don't deem this to be a problem. We already need to ship custom-built binaries in order to avoid platform version compatibility issues, so this won't change much overall.