[Interest] #include <QtPlatformHeaders/QCocoaNativeContext>
Glenn Ramsey
gr at componic.co.nz
Mon May 4 05:39:44 CEST 2020
On 4/05/20 1:09 pm, Thiago Macieira wrote:
> On Sunday, 3 May 2020 16:48:45 PDT Glenn Ramsey wrote:
>> Qt is a cross platform C++ framework and presumably its users (who are C++
>> developers and not necessarily platform experts) expect some sort of
>> insulation from platform issues. In this case it is unavoidable so it would
>> be a courtesy to those non-mac developers to mention in the documentation
>> for
>> QCocoaNativeContext that it is not a C++ header and can only be included in
>> an Objective-C++ file.
>
> And Qt does that, so long as you're using the Qt API. But you specifically
> included a "platform header" with "Cocoa" in the name. The module in question
> by its very name means it's not insulating you from the underlying API. If
> you'd included the GLX header, you'd have to deal with its very C-ish way of
> doing things.
>
> They also mean you must be reading the documentation of the API in question.
> And if you're reading Cocoa documentation, you'll probably have seen all those
> extra brackets that make no sense in C or C++.
>
> Why did you include this header?
The app I'm working on embeds Ogre3D in a Qt window. It also uses
QWebEngineView, which doesn't draw anything if the embedded Ogre3D is animating.
>From what I can gather this is because there needs to be a shared OpenGL context
(possibly another question coming about that soon). What I'm trying to do is to
get an OpenGL context that I can pass to Ogre3D to set up sharing. I'm not
accessing the API at all and Ogre takes the pointer to the context as a string
representation of a decimal integer.
If I had been attempting to actually use the NSOpenGLContext pointer that
QCocoaNativeContext::context returns I would probably have needed other headers
and the issue would have been more obvious. As far as I know, on the other
desktop platforms, i.e. Windows and Linux, the native APIs are in C so including
the relevant QtPlatformHeaders files to simply obtain a pointer should 'just
work'. That is how I was thinking about it at the time.
It would have saved me a bit of mental tax if there had been a note in the
documentation drawing attention to the fact that this one particular header is
Objective-C++.
Glenn
More information about the Interest
mailing list