[PyQt] Expose QOpenGLContext::getProcAddress?

[Phil Thompson]

On 14/04/2019 01:55, Georg Brandl wrote:
> Am 13. April 2019 14:00:39 MESZ schrieb Phil Thompson
> <phil at riverbankcomputing.com>:
>> On 13 Apr 2019, at 3:33 pm, Georg Brandl <g.brandl at fz-juelich.de>
>> wrote:
>> 
>>> On 12.04.19 22:55, Phil Thompson wrote:
>>> On 12 Apr 2019, at 10:49 pm, Georg Brandl <g.brandl at fz-juelich.de>
>>> wrote:en thou
>>> 
>>> Hi,
>>> 
>>> for integrating a PyQt application with OpenGL drawing in an
>>> extension module written in another language, it would be useful to
>>> have this method exposed in the QOpenGLContext class.
>>> 
>>> It is already exposed in the legacy QGLContext class, and I can use
>>> that for now, but from the docs it sounds like the QGL classes
>>> should not be used anymore.
>>> Just because it is exposed doesn't mean it is useful. As I understand
>>> it it returns the address of a C function wrapped as a sip.voidptr.
>>> Is that useful?
>> Yes, that's what it does.  It seems that the OpenGL library is usually
>> loaded at runtime by some helper library, and individual functions are
>> resolved with dlsym.  That way, applications can react to various
>> functions and extensions being available or not.
>> 
>> Qt has it in the QOpenGLContext class, and for example, PyOpenGL
>> does it via ctypes.  Other GL helper libraries like GLFW have them
>> as well:
>> https://www.glfw.org/docs/latest/group__context.html#ga35f1837e6f666781842483937612f163
>> 
>> My drawing code, being written in Rust, also depends on a function
>> that resolves the functions at runtime.  Since I'd like to make sure
>> that the functions are resolved in the same way that Qt already does
>> for the calls it makes internally for the widget, I'd like to pass
>> QOpenGLContext::getProcAddress to it, via a Python callback function.
>> 
>> I understand how it is supposed to work but PyQt doesn't support the
>> calling of arbitrary addresses even though the inclusion of
>> getProcAddress() might suggest otherwise.
> 
> That doesn't matter for my case, I don't need to call the function
> pointer from Python. Just need to pass it down to the Rust code, which
> knows how to use it. As I said, it works fine with the equivalent
> method on the legacy class.

Sorry I hadn't realised the legacy class worked. Try the next snapshot 
(untested).

Phil