[Interest] Future of Qt with Ios
Till Oliver Knoll
till.oliver.knoll at gmail.com
Fri Sep 12 15:43:03 CEST 2014
Am 12.09.2014 um 14:26 schrieb Karl Loveridge <KLoveridge at eatsleepplay.biz>:
> ...
> My request as an end user is for Qt, at the very least, to make it easy for us to set up a Widget based on either OpenGL
You have it: QGLWidget (deprecated), QOpenGLWidget (new replacement for QGLWidget since Qt 5.4), or QWindow (set its "surface type" to OpenGL) - the later lets you to "get as close as possible to the underlying native window resources" - and preferrable if you want to have "full screen applications" anyway.
> or Metal.
In contrast to OpenGL which is available wherever Qt runs and compiles Metal is not a cross-platform API. So it would make little sense for Qt - being a cross-platform API itself - to wrap a platform-specific API into its own public API (such as e.g. a QMetalWidget). (*)
That said, Qt /does/ expose certain "under the hood" resources such as native "window handles" (e.g. QWidget::effectiveWinId()). As you're on the "platform-specific code" train anyway already when thinking about "Metal" it should be possible to integrate a "native Metal window/surface/whatever" resource into an existing Qt application. Whether into an existing parent widget or as "full screen" window (and merely use the Qt event queue to process input events, networking or whatever might be helpful for a "game kit based on Qt").
Cheers,
Oliver
(*) Exceptions confirm the rule: so yes, there are Qt classes which wrap "ActiveX components" on Windows (only).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140912/40b33036/attachment.html>
More information about the Interest
mailing list